How can I use Whole Program Optimization feature in Free Pascal 2.7.1 on Windows?
I get this error:
Project1.dpr(92,1) Fatal: Cannot find "nm.exe" or "" to extract symbol
liveness information from linked program
The problem is the WPO is trying to extract symbols from your executable using NM. NM is not available for Windows.
The good news is, Windows has DumpBin instead. I think you can use this directly in place of NM.
Related
Is it possible to get a complete disassembly (which can act as input to an assembler) of an executable?
When I use otool -tV a.out I get to see only the text section. Other sections like data aren't visible.
When I use gdb, the disassemble command requires a start and an end address. However I do not know how to find out the start and the end address of a binary (say a.out).
I'm trying to disassemble an executable, tinker with the assembly code and then reassemble it.
Is that possible?
It'd also help if one can find out the names of all the sections in a binary.
Try using this command, i remember using it sometime back:
otool -tvV a.out
On Mac, you can install (possibly by homebrew) binutils that includes gobjdump. You can disassemble any binary program once installed. It's open and free.
You can use the Hopper Disassembler
quote:
Hopper is a reverse engineering tool for the Mac, that lets you disassemble, decompile and debug your 32/64bits Intel Mac executables.
It costs $59, but you can download a demo to check if it gets the job done first.
EDIT
It seems you can achieve this with otool as well, according to the manual.
.B -d
Display the contents of the (_^_DATA,_^_data) section.
Also have a look at this short blog post (archive link, original is gone) that describes the mentioned use of otool, and how you can use objdump as mentioned by #Sjlver.
On linux, you can try to use objdump -D myprog
Note that this will work only if the program does not contain irregular control flow. Especially malware is often obfuscated, e.g. by inserting spurious bytes that are then jumped over.
If you're targeting this kind of programs, I've heard that one of the best products to use is IDA pro.
Windows XP:
I ultimately wanted to install DDD (the debugger). Its not available in binary form for Windows. When I got its source and tried to configure it, it complained that no term caps library was present. So I acquire ncurses and got this after a mostly successfull build using Cygwin Terminal:
../lib/libncurses.a(lib_ttyflags.o)(.text+0x41):lib_ttyflags.c: undefined reference to `_nc_mingw_ioctl'
../lib/libncurses.a(lib_ttyflags.o)(.text+0xd1):lib_ttyflags.c: undefined reference to `_nc_mingw_ioctl'
It works for me when I do this:
configure --enable-term-driver --enable-sp-funcs
make
The --enable-term-driver was needed for "mingw" (I tested on msys, but this should work equally well on cygwin), and --enable-term-driver requires --enable-sp-funcs.
--enable-sp-funcs
compile-in support for extended functions which
accept a SCREEN pointer, reducing the need for
juggling the global SP value with set_term and
delscreen.
--enable-term-driver
compile with terminal-driver. That is used in the
MinGW port, and (being somewhat more complicated)
is an experimental alternative to the conventional
termlib internals. Currently, it requires the
sp-funcs feature to be enabled.
See here: http://lists.gnu.org/archive/html/info-gnu/2011-02/msg00020.html
I need to create an ELF image file from shared objects (.so files) and write it to another partition in Windows. Then open this partition in Linux and load the shared objects.
Does anybody know how to create an ELF image (a bundle of many shared objects) in Windows?
You can use Cygwin and try a suitable GCC cross-toolchain. Perhaps you'll have to build it yourself first (which is troublesome), but there it goes...
EDIT:
Okay, here you are:
A simplified one:
Building GCC cross compiler (from "Linux" to "Windows") -- the basic steps are the same as described there. You'll just need to ./configure it with relevant --host=... and --target=.... And oh! Don't forget to set the build root, since building "in the source tree" is not supported -- you'll just get stuck in errors if you try (I did...)
A killer one:
http://cygwin.wikia.com/wiki/How_to_install_a_newer_version_of_GCC#Build_and_Install_GCC -- a complete guide.
Nowadays Linux understands NTFS. At least, it should be able to read off it.
You can also use a flash stick formatted as FAT32 or NTFS as the shared storage.
You can also run Linux in a VM and set up FTP server on it and exchange files through it.
There're many ways of sharing data between different OSes.
What is the need/use of 'symbols' in the Microsoft debugger?
I spent some time trying to figure out the debugger a while back and never was able to get it making any sense (I was trying to debug a server hang...). Part of my problem was not having the proper 'symbols'.
What are they? And why would I need them? Aren't I just looking for text?
Are there any better links out there to using it than How to solve Windows system crashes in minutes ?
You need symbols in order to translate addresses into meaningful names. For example, you have locations on your stack at every function call:
0x00003791
0x00004a42
Symbols allows the debugger to map these addresses to methods
0x00003791 myprog!methodnamea
0x00004a42 myprog!methodnameb
When you build a debug version of a program, the compiler emits symbols with the extension .PDB. It also contains line information so you can do source code debugging, etc..
You need to set your symbol search path correctly for the debugger to pick this up. IN the command window you can do
.sympath c:\symbols;c:\temp\symbols
in order to have it search for the .PDB in these directories. It will also look in the same directory that the executable is ran from.
It also might be helpful to use the Microsoft public symbols server so that you can resolve OS binaries such as NTDLL, GDI, etc.. with this path at the beginning:
.sympath SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols;c:\symbols
You will need to create c:\websymbols first.
On the Windows binary architecture, the information needed for debugging (function names, file and line numbers, etc.) aren't present in the binary itself. Rather, they're collected into a PDB file (Program DataBase, file extension .pdb), which the debugger uses to correlate binary instructions with the sorts of information you probably use while debugging.
So in order to debug a server hang, you need the PDB file both for the server application itself, and optionally for the Windows binaries that your server is calling into.
As a general note, my experience with WinDbg is that it was much, much harder to learn how to use compared to GDB, but that it had much greater power once you understood how to use it. (The opposite of the usual case with Windows/Linux tools, interestingly.)
If you just have the binary file, the only info you can typically get is the stack trace, and maybe the binary or IL(in .NET) instructions. Having the symbols lets you actually match that binary/IL instruction up with a corresponding line in the source code. If you have the source code, it also lets you hook up the debugger in Visual Studio and step through the source code.
I have some crashes in some C code, built without debugging symbols, and I have only a backtrace with the absolute addresses of the call stack. This is on windows (64 bits). I am more of a linux guy, so I am a bit lost at how to look into debugging this - on Linux, I would run the code under valgrind, but AFAIK, no such tool exists for windows 64 bits.
What are my options ? I can modify the C code at will, but I cannot build it with the debug symbols. The reason why I cannot build with debugging symbols is that my binary is not built with MS tools (it is built with mingw-w64).
You need to generate a map file. A map file lists out the addresses of various public symbols (functions, globals etc) in your executable/binary. Usually it can be generated by passign on a special switch to the linker.
MSDN reference for /MAP
You should probably be using the ming version of gdb, which can understand the symbols embedded in the binary.