During the work I faced with the following problem:
I need to parse GDB debug info.
Separate debug info file is a binary, so I can not read it without knowing a format.
So, here is the question:
Is there any ready parser for GDB info, or at least document describing it?
Is there any ready parser for GDB info
There is no such thing. There are various debug info formats (DWARF, STABS, etc.) and multiple consumers of these debug formats (GDB is one such consumer).
If you are on Linux, the default debug format is DWARF, documented here.
I need to parse ... debug info
Depending on your actual needs, readelf -w or already mentioned libdwarf may be appropriate. Or you could write your own parser from scratch, though it's unlikely to be the optimal solution.
You should probably take a look at libdwarf. See http://sourceforge.net/projects/libdwarf/ or http://wiki.dwarfstd.org/index.php?title=Libdwarf_And_Dwarfdump
Related
if I accidentally forget to switch to release configuration before releasing my program, does it matter in terms of it being easier to decompile or reverse engineer my code?
For example if I accidentally use the following debug compiler options:
1. Compiling:
- StackFrames = True
2. Debugging
- Debug information = Debug information
- Local Symbols = True
- Symbol Reference info = Reference Info
3. Linking
- Map File = Detailed
I have read help and from what I can tell it doesn't make much difference unless the map file is also somehow released with the binary file, so I wonder how much a difference it makes if someone has the map file?
Let's clarify one by one the options you've mentioned:
Compiling > Stack frames: Stack frames are only needed for debugging (and maybe to generate stack traces for error reporting, as mentioned by #DavidHeffernan in the comments). Even if you enable it in release builds, that won't be very helpful for reverse engineering.
Debugging > Debug information: With this option set, the debug information is compiled inside the DCUs to help debugging inside the IDE. It's not linked into the exe, so it's obvious that it won't help reverse engineering.
Debugging > Local symbols: With this option set, the compiler includes basic symbol information in the debug info, but again, it only helps when debugging on the IDE and it's not linked into the final exe.
Debugging > Symbol reference info > Reference info: Additionally to the previous option, this one includes detailed information about unit-local symbols (variables, constants, classes and so forth) to aid in debugging. They're also not linked into the final exe.
Linking > Map file > Detailed: With this option set, the linker will create a detailed .map file containing all the information (type, name, address, size, etc.) about program's symbols, so, of course it would be helpful for reverse engineering IF you distribute this file along with your exe (as stated by #RemyLebeau in the comments).
There's also the option to generate remote debug symbols, as pointed by #dummzeuch:
Linker > Include remote debug symbols: This option tells the linker to generate a .rsm file, it's the Delphi equivalent of Microsoft's .pdb Program Database Files. If you distribute this file, you could be on real trouble, because one could easily debug your application, visualize symbols, functions and procedures, single-step your code and so on.
Also, I think it's important to say that .map files are not equivalent to .pdb files. For Delphi Win32, .rsm is the equivalent. I have not worked with Delphi for years, but as far as I can remember, no Delphi Win32 version can generate .pdb files. Only Delphi for .NET can.
That said, let's go back to your questions:
I wonder how much a difference it makes if someone has the map file?
Reverse engineering would be much easier having a .map file. I've seen some tools in the past that can even convert a .map file to a .dbg file for use with a debugger.
Is it easier to reverse engineer or break a Delphi program if the exe file was compiled with debug compiler settings?
Well, one important (and maybe the most noticeable) characteristic of Debug builds is the bigger exe size. That's mainly because in the Debug configuration the compiler disables a number of code optimizations in order to facilitate code debugging. There's also a lot of debug-conditional code (eg.: inside {$IFDEF DEBUG} directives) that gets linked into the exe.
As a side effect, the code generated by a Debug build is much easier to reverse engineer because it's simpler to understand.
I've done some search out there but couldn't find too much really helpful info on it, but could someone try to explain the basic of Java memory maps? Like where/how to use it, it's purpose, and maybe some syntax examples (inputs/outputs types)? I'm taking a Java test soon and this could be one of the topics, but through all of my tutorials Jmap has not come up. Thanks in advance
Edit: I'm referring to the tool: jmap
I would read the man page you have referenced.
jmap prints shared object memory maps or heap memory details of a given process or core file or a remote debug server.
NOTE: This utility is unsupported and may or may not be available in future versions of the JDK. In Windows Systems where dbgeng.dll is not present, 'Debugging Tools For Windows' needs to be installed to have these tools working. Also, PATH environment variable should contain the location of jvm.dll used by the target process or the location from which the Crash Dump file was produced.
http://docs.oracle.com/javase/7/docs/technotes/tools/share/jmap.html
Its not a tool to be played with lightly. You need a good profiler which can read it output as jhat is only useful for trivial programs. (YourKit works just fine for 1+ GB heaps)
What console output commands are available in Erlang?
I know about io:format but was wondering what other output libraries exist.
For quick debugging, I find quite useful the erlang:display/1.
I wish to debug executables for which I have no code, using the Delphi Debugger.
WinDBG and other debuggers are no option in this case, as the given executables all call into my DLL, for which I do have code, obviously. My ultimate goal is, to see a stack-trace right down into the functions of the running executable.
I do have symbol-information for these executables, so I was hoping I could write my own .RSM files for this purpose. Will this work? Will the Delphi debugger pick up any .RSM file that it can find? And would that mean that other debug-information should be left out?
Do note that there are lots of executables that I need to debug, and for all of them I detect the symbols inside them myself, using a moderately advanced function-detection algorithm. So my main problem mainly is how to write .RSM files. For this I have to know the structure of the .RSM file-format. Is there documentation or example code available somewhere that shows me how to create such a file?
Any help is appreciated!
PS: Might you be wondering why I'm doing all this : It's all related to Dxbx - an open-source Xbox1 emulator. See sourceforce for details. New members are welcome!
I found a page that says the format is similar to CodeView (www.openwatcom.org/index.php/Debugging_Format_Interoperability)
There is a link to this reference at Microsoft's CodeView format specs
I doubt this fully answers your question, but maybe it will get you a little further?
I am attempting to use WinDBG or another debugger to debug a CodeGear Delphi 2007 Windows application on a remote machine. I have been unable to produce symbol files for WinDBG.
Is there a way to use WinDBG or another debugger to debug Delphi applications on a system that doesn't include the IDE?
Edit1
The remote debugger is not an option here. I am able to remote in to the end user PC, but I am unable to use the remote debugger due to firewall restrictions.
Edit2
I am able to remote in to the machine, but can not connect the CodeGear remote debugger due to firewall restrictions.
How about the remote debugger? Build your app with remote debug symbols and debug from your development machine across the network.
instead, i rely on MadExcept stack tracing and some logging features. my application is distributed worldwide & this has been sufficient.
You can try generating a map file and then convert it to a dbg file using map2dbg from
http://code.google.com/p/map2dbg/
Then you can load the dbg file in WinDbg.
Disclaimer: I had faced a similar issue but I managed to do remote debugging and didn't have to do all this. So I am not sure this will work. But if you try it then do let us know if it works.
I'm afraid this is one more of those "I don't have an actual answer" answers, but it might just help...
Have you considered adding logging to your application? I've heard great things about SmartInspect. With it, you can log all sorts of information, including stack traces and "watches" (variables).
Another logging product for Delphi is EurekaLog.
In Delphi you could use Run -> Attach to Process, select the remote machine and select the process you'd like to debug.
http://sourceforge.net/projects/tds2dbg/ can be used to convert Delphi's TDS debug files to DBG files. This gives basic symbol information -- functions, classes, units, but not variables. Enough for a reasonable call stack, and with a bit of knowledge, enough to debug Delphi apps live and with dumps.
I've written about some of Delphi+WinDBG experiences on my blog: https://marc.durdin.net/2015/11/windbg-and-delphi-a-collection-of-posts/
Thank you all for the great suggestions and interesting products.
To solve this specific issue, the "best" way I found uses the OutputDebugString located in the Windows namespace. This, along with Debug View from Sysinternals, will allow me to gather debug information and sort through it pretty quickly.
If you decide to use this method, make sure everything is wrapped in ANSI formatting. IE:
OutputDebugString(PAnsiChar(string1 + string2));
This makes sure that string1 and string2 are combined and then converted in to ANSI Characters.
I probably should have just started dumping text to a file for something quick and dirty, but this will allow a non-debugging version to emit debugging messages.