I have compiled a string matching tool SMART in windows using MSYS2, the tool is implemented in C programming language. The instruction was (in the the instruction set):
makefile is the bash file used for compiling the C source files of the tool. Run the command ./makefile in order to compile the smart
tool. The code of each string matching algorithm is compiled an
tested separately.
The problem now is, each algorithm is compiled properly but tested unsuccessfully.
Also, when the following command is given to execute (see how to run experimental tests):
./smart -text englishTexts
I get the following error:
shmget: Function not implemented
I doubt both issues are related/due to the failure of managing shared memory, note that author created the system on a POSIX system (whereas I am trying to run this on a Windows system). Author wrote about the Manage shared memory on LINUX:
In order to configure shared memory on linux you have to login as
root, then edit the file
/etc/sysctl.conf.
The kernel.shmax parameter defines the maximum size in bytes for a
shared memory segment. Determine the value of kernel.shmax by
performing the following:
cat /proc/sys/kernel/shmmax
33554432
The kernel.shmall parameter sets the total amount of shared memory in
pages that can be used at one time on the system. Set the value of
both of these parameters to the amount physical memory on the machine.
As in the previous case you can determine the value of kernel.shmax by
performing the following:
cat /proc/sys/kernel/shmmall
2097152
Set the values of kernel.shmax and kernel.shmall, as follows:
echo MemSize > /proc/sys/shmmax
echo MemSize > /proc/sys/shmall
where MemSize is the number of bytes. For example, to set both values
to 2GB, use the following:
echo 2147483648 > /proc/sys/kernel/shmmax
echo 2147483648 > /proc/sys/kernel/shmall
Then reboot the machine using. Shared memory can be viewed with the
ipcs command and you can delete shared memory segments with the ipcrm
command.
But there is nothing specific about Windows (though there is a paragraph for "Manage shared memory on WINDOWS VISTA").
At this point I ask your help, to inform me whether there is a package for MSYS2 to solve shmget error mentioned above? Or there are other ways to solve this problem?
Unfortunately I think you're out of luck with msys2. msys2 takes out cygserver from cygwin, which is required for shared memory.
Related
Consider the following code in mono/domain.c:
static MonoDomain *mono_root_domain = NULL;
...
MonoDomain* mono_get_root_domain (void)
{
return mono_root_domain;
}
My task is to read the struct data pointed by the mono_root_domain pointer in runtime from another process. (Attaching, reading, locating dylibs, etc. from this other process is solved already)
Looking into the generated libmono dylib I can find the corresponding symbol:
This symbol points to the address of 0x2621A8 which in the local relocation section (__DATA, __bss):
This points to the address of 0x1A7690 (__TEXT, __symbol_stub):
The target is
so 0x1A7DF8 (__TEXT, __stub_helper):
At this point I am completely lost of how to retrieve the actual pointer to the MonoDomain struct. Any help is appreciated.
For security reasons and to prevent buffer overflow attacks and other exploits, you can't know that, because of a security measure called PIE or ASLR (address space layout randomization). However, this can be disabled for debugging purposes. LLDB and GDB do/did it in order to debug executables. The way this can be done with a CLI app is as follows:
Copy or download this python script from GitHub
https://github.com/thlorenz/chromium-build/blob/master/mac/change_mach_o_flags.py
Save the python script, for example, next to your executable
If so, open Terminal and cd to where your executable is
enter chmod +x ./change_mach_o_flags.py to make the script executable
enter ./change_mach_o_flags.py --no-pie ./YourExecutable
Now the addresses of your executable should not be randomized anymore. Because of that, to calculate the addresses of your static / global variables is possible. To do that, do the following in Terminal (I am assuming you are using a 64-bit machine):
otool -v -l ./YourExecutable | open -f(this will generate a file text with the commands inside your executable of how to layout DATA, TEXT, etc. in memory)
Look for the section you are interested in. Look at the addr field. If it contains let's say 0x0000000100001020 then the variable will be placed exactly there with ASLR disabled.
I am not sure if this works with dylibs but you can try it. Now I ran out of time, but I can try at home and see if this is doable with dylibs.
I have been using the deploytool in Matlab for the past few months in my 2010b 64bit version of Matlab. I just recently found out that I need to create a 32 bit version of my c shared library.
To do this I follow the same methods I had been using previously (pretty much calling the command mcc -W lib:MYLIB -T link:lib -d 'MYOUTPUTFOLDER' -v 'MFILE1' 'MFILE2') in my 2009b 32 version of Matlab. I keep getting the error LNK1811: cannot open input file LIBRARY.obj. I have tried to find this LIBRARY object file but I cannot seem to find it anywhere.
So far I have checked to ensure all of the correct libraries are available (found at $MATLABROOT$\extern\include\win32), I have made sure all of my paths are correct in the compopts.bat file, and I have used the option -T compile:lib which works fine and creates a dll. This would be great but I need a lib file to use later in mbuild.
My current path forward is to take the compopts from my 64 bit version of Matlab (on a different machine) and compare it with my compopts for the 32 bit. I will post if it makes a difference.
To summarize our comments in the question and make it an answer. Here is how I manage to create both x32 and x64 libraries/standalones with mcc.
NB: Maybe there are more elegant solutions to configure deploytool, anyway with brute force I'm sure it works and I can automate global deployment process for my applications ...
Machine setup
Install Matlab x32 and x64 on your machine
Run Matlab x32 and setup compiler options typing msbuild -setup
This will generate a compopts.bat file in ~user\AppData\Roaming\MathWorks\MATLAB\R2013b (path may differ upon your version)
Rename this file to compopts.x32.bat (see later)
Run Matlab x64 and setup compiler options typing msbuild -setup
This will generate a compopts.bat file in ~user\AppData\Roaming\MathWorks\MATLAB\R2013b (!!Overwrites x32!!)
Rename this file to compopts.x64.bat (To workaround file overwrite)
EDIT Just tested ... In R2014b, Matlab does no longer overwrites same compots.bat file ... it now generates two separate MBUILD_C++_win64.xml and MBUILD_C++_win32.xml files (which is a good thing!).
Compilation in x32
Force your compilation script to point to ~matlabx32\bin\win32\mcc.exe and force mcc.exe to use previously saved compopts.x32.bat file using the -f option. Your command line should be something like:
~matlabx32\bin\win32\mcc.exe -f "compopts.x32.bat" ... other mcc options ...
Compilation in x64
Force your compilation script to point to ~matlabx64\bin\win64\mcc.exe and force mcc.exe to use previously saved compopts.x64.bat file using the -f option. Your command line should be something like:
~matlabx64\bin\win64\mcc.exe -f "compopts.x64.bat" ... other mcc options ...
Consider the following Linux kernel dump stack trace; e.g., you can trigger a panic from the kernel source code by calling panic("debugging a Linux kernel panic");:
[<001360ac>] (unwind_backtrace+0x0/0xf8) from [<00147b7c>] (warn_slowpath_common+0x50/0x60)
[<00147b7c>] (warn_slowpath_common+0x50/0x60) from [<00147c40>] (warn_slowpath_null+0x1c/0x24)
[<00147c40>] (warn_slowpath_null+0x1c/0x24) from [<0014de44>] (local_bh_enable_ip+0xa0/0xac)
[<0014de44>] (local_bh_enable_ip+0xa0/0xac) from [<0019594c>] (bdi_register+0xec/0x150)
In unwind_backtrace+0x0/0xf8 what does +0x0/0xf8 stand for?
How can I see the C code of unwind_backtrace+0x0/0xf8?
How to interpret the panic's content?
It's just an ordinary backtrace, those functions are called in reverse order (first one called was called by the previous one and so on):
unwind_backtrace+0x0/0xf8
warn_slowpath_common+0x50/0x60
warn_slowpath_null+0x1c/0x24
ocal_bh_enable_ip+0xa0/0xac
bdi_register+0xec/0x150
The bdi_register+0xec/0x150 is the symbol + the offset/length there's more information about that in Understanding a Kernel Oops and how you can debug a kernel oops. Also there's this excellent tutorial on Debugging the Kernel
Note: as suggested below by Eugene, you may want to try addr2line first, it still needs an image with debugging symbols though, for example
addr2line -e vmlinux_with_debug_info 0019594c(+offset)
Here are two alternatives for addr2line. Assuming you have the proper target's toolchain, you can do one of the following:
Use objdump:
locate your vmlinux or the .ko file under the kernel root directory, then disassemble the object file :
objdump -dS vmlinux > /tmp/kernel.s
Open the generated assembly file, /tmp/kernel.s. with a text editor such as vim. Go to
unwind_backtrace+0x0/0xf8, i.e. search for the address of unwind_backtrace + the offset. Finally, you have located the problematic part in your source code.
Use gdb:
IMO, an even more elegant option is to use the one and only gdb. Assuming you have the suitable toolchain on your host machine:
Run gdb <path-to-vmlinux>.
Execute in gdb's prompt: list *(unwind_backtrace+0x10).
For additional information, you may checkout the following resources:
Kernel Debugging Tricks.
Debugging The Linux Kernel Using Gdb
In unwind_backtrace+0x0/0xf8 what the +0x0/0xf8 stands for?
The first number (+0x0) is the offset from the beginning of the function (unwind_backtrace in this case). The second number (0xf8) is the total length of the function. Given these two pieces of information, if you already have a hunch about where the fault occurred this might be enough to confirm your suspicion (you can tell (roughly) how far along in the function you were).
To get the exact source line of the corresponding instruction (generally better than hunches), use addr2line or the other methods in other answers.
I don't understand why the following code returns "'bcdedit' is not an internal or external command" when ran from a c program. bcdedit works perfectly fine on cmd line. How can I get this to work?
#include <stdio.h>
int main ()
{
system("bcdedit");
system("TIMEOUT /T 3");
return(0);
}
It happens because when you run the Command Prompt via Start Menu or even the Execute window you are running the 64-bit cmd version, located at C:\Windows\System32\cmd.exe, however when call cmd from your c program it calls the 32-bit cmd version, located at C:\Windows\SySWOW64\cmd.exe. This happens because your C compiler generates a 32-bit application.
According to MSDN:
The %windir%\System32 directory is reserved for 64-bit applications.
Most DLL file names were not changed when 64-bit versions of the DLLs
were created, so 32-bit versions of the DLLs are stored in a different
directory. WOW64 hides this difference by using a file system
redirector.
In most cases, whenever a 32-bit application attempts to access
%windir%\System32, the access is redirected to %windir%\SysWOW64.
Source: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx
If you compare both cmds you will realize that they are identical, what differs are the dll's.
The problem is that Windows x64 provides a 64-bit bcdedit.exe in the System32 folder, but doesn't provide a 32-bit bcdedit.exe anywhere. So the 32-bit cmd can't run the 64-bit bcdedit, so it returns that this command is invalid.
Solution: You can both obtain a 32-bit bcdedit from a Windows x86 version or you can compile a 64-bit application.
Most likely because it cannot find the executable. Either ensure your path is correct(a) or use the full path name:
system ("c:\\windows\\system32\\bcdedit.exe");
And, of course, this should go without saying: make sure you run it as an administrative user.
(a) You should be able to confirm this with something like:
system ("path");
I think you have cut one command into two part.And I think you want to run "bcdedit.exe /timeout 3",but you give the
argument of the system command two parts, one is "bcedit.exe", another is "/timeout 3". I think you should wrote this
system("bcdedit.exe /timeout 3");
to run the command you wanted.Hope this will help you
I have a program which compiles and runs scripts.
To create a standalone version of the script, I reserve a large static buffer to hold the compiled script. The compiled script is copied into a copy of the program and it can then be run from that copy.
This works fine. It has some disadvantages however:
the buffer is static and takes up space if there's no compiled
program in it.
if the script to be included exceeds the buffer's size, I need to build a new version with a larger buffer.
I'd like to add the compiled script to the end of the program, but naively doing so doesn't work as the exe loader chokes on the new file size.
Is there a way to manipulate the exe so it would be acceptable for the loaders (mind this is a cross platform program)?
would be acceptable for the loaders (mind this is a cross platform program)?
I would think that this is unlikely to be possible without being platform specific. Time for a common interface with different implementations (so the code that saves/loads the script is common, but the executable manipulation is specific).
On Windows you'll hit the problem that a running executable file is locked against modification. By working on copies this can be worked around (but the only way to rename back in a completely deterministic way it is perform the move on boot, but scheduling a job might be acceptable).
On Windows the easiest way to add data to an image (executable or dll) is using resources. Define a custom resource type and add into the image (UpdateResource function) and later retrieve with LoadResource.
You said "script", so I suppose you have a separate file containing the script (a text file?). You could write a simple program that reads the script file and convert it in a compilable form (e.g. a C source containing the initialization of an array of byte). There are also tools you can use to convert an arbitrary file into a linkable object (.o or .obj). In the past I have used the command "objcopy" from GNU bimutils. In particular, on linux:
objcopy -I binary -O elf32-i386 mydata mydata.o
This command creates an object and three public symbols you can use to find the start, the end and the size of your data block:
_binary_mydata_start
_binary_mydata_end
_binary_mydata_size
Something similar may work also on Windows, provided that you install a Windows version of GNU binutils (e.g. cygwin).