[SOLVED] Debug symbols file format

[alpine]

Can anyone give me some directions about the format of the FPC debug symbols file? Are there some already pre-brewed units/sources to read it? Or utility to dump it in a friendly manner?

Thanks in advance!

[Jonas Maebe]

On most platforms, DWARF-2 is the default (-gw): http://dwarfstd.org/Download.php

On some older platforms, it's Stabs: http://www.sourceware.org/gdb/5/onlinedocs/stabs.pdf

In both cases, the debug information is either stored inside the binary itself, or in an object file native to the target platform.

We have some basic units, but they only support parsing the line information (for use by the functionality of the -gl parameter): exeinfo (general binary/object parsing), lineinfo (Stabs) and lnfodwrf (DWARF).

[Martin_fr]

fpc can write stabs (on some systems only), and dwarf 2, 3 or 4 http://dwarfstd.org/

* There are units LineInfo and InfoDwrf (IIRC, or similar named). Those read line info.
* There is a util called objdump, that can extract the info.
* There is components/fpdebug which reads lots of the dwarf info.

There are 1 or 2 external projects, IIRC duby, and an alternative fpdebug... Similar to the included fpdebug.
It is possible that one of them has some stabs support. No idea....

[440bx]

In addition to what Jonas and Martin stated, if you don't mind reading C code, you might want to check out Libdwarf and Dwarfdump.  (Google Libdwarf)

Michael J. Eager wrote a nice introduction to DWARF in pdf format.  The link to that document is http://dwarfstd.org/doc/Debugging%20using%20DWARF-2012.pdf

HTH.

[alpine]

Many thanks for the responses!

components/fpdebug was something under my nose that I didn't noticed. Searched fpcsrc/packages, lazarus/debugger but it seems I didn't look very hard.

Despite my vague questioning, I'm actually interested in the line debug info, because I want to find a ways to refactor a *big* code base and to throw away the dead code without 'walking' the blue balls in debug mode. I thought the debug symbols file is a good point to start.

* There is a util called objdump, that can extract the info.

Maybe the objdump is the tool I need for the purpose, but I can't realize the options to invoke it right, I'll be happy to have the sorce file names and line numbers of the code finally left into the executable. Is it possible to get them with some magic combination of options?

[Martin_fr]

If you are looking at code in packages, then make sure those packages have the correct debug info set too.
If it is only project files, then that is covered by the project settings.

Code: [Select]

objdump.exe --dwarf=decodedline project1.exeMind, that may include units from packages. So the output can be huge.

You can also play with wpo (whole program optimization).
Search the wiki. It's an fpc feature, where you compile several times, and the compiler uses info from the last compile to further optimize the next compile.
I.e. it can then detect, if a virtual method gets called or not, and if not, it can drop it, and in the next run drop further stuff, if it was only hold by the now dropped method.

[alpine]

@Martin_fr
Thanks! That is what I need.