Hi, On Mon, 23 Aug 2010 10:23:52 +0200, Graeme Geldenhuys <[email protected]> wrote: > Hi, > > When you add the -gl (debug line info added to compiled executable) > parameter to a project, which unit does it use to gather the debug > information? > > LineInfo (via stab information) or LnfoDwrf (via dwarf information)? > > How do you toggle between the two? How do I know which one of the two > is being used?
You toggle using the -gX options. -gs forces stabs, and -gw forces dwarf. The default selects according to the platform. I remember the logic is something like this: 32 bit systems (except on OSX iirc?): stabs 64 bit systems: dwarf Do not bother forcing stabs on 64 bit systems. It will not work correctly and is not supported. > At the moment, when I compile with -gl, then the GetLineInfo doesn't > return any function name information. I then removed the -gl and > explicitly added LnfoDwrf into my project uses clause (thinking that > Stab info might be old and outdated), and still the function name Stabs is old and outdated, but it has the advantage that it can print the function information. See below too. > information return by GetLineInfo was blank. I'm testing on a 64-bit > Linux system. A limitation of the current dwarf reader is that it only parses the so-called "debug_line" section of the DWARF debug info containing a mapping from instruction address to a line number. There is no information about the function (or "compilation unit") which is currently being processed there. The mapping from address to a function name is stored in a different section of the DWARF debug info, called "debug_aranges" which provides a mapping of instruction addresses to function names. The compiler does not generate a "debug_aranges" section as far as I know. If it were available, adding this feature would be straigthforward. The other option would be to parse the whole DWARF debug info to associate an instruction address to a function name. If the line number output of the lnfodwrf unit does not match the actual source line, you found a bug in the compiler or RTL. Hth, Thomas _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
