[fpc-devel] Which unit does -gl parameter use?
tom_at_work at gmx.at
Mon Aug 23 11:24:34 CEST 2010
On Mon, 23 Aug 2010 10:23:52 +0200, Graeme Geldenhuys
<graemeg.lists at gmail.com> wrote:
> 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
> 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
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.
More information about the fpc-devel