Just over a year ago, Frank van der Linden reported to this list:

> After the recent switch of the i386 port to ELF, people noticed that
> gdb gets linenumbers wrong sometimes. I looked into this, and found
> that it gets them wrong when it has to match a symbol -> linenumber,
> or, to be more precise, PC -> linenumber.
>
> It turns out that it's not actually gdb's fault (I think).

   [ ... ]

> There seem to be 2 problems here:
> 
>         * For the i386, the linenumber information lies outside
>           the function information, which can't be correct.
>         * The values of the SLINE symbols (which are the matching
>           PCs at which this line is located) are supposed to be
>           relative to the start of the function. This is correct
>           in the sparc binary, but ld(1) has made them absolute
>           already on the i386 port, which is wrong.
> 
> Looking at the gdb code, it uses the N_FUN stab to get the
> start of the function, and then adds the offset in the N_SLINE
> stab to get the PC. So for the i386, this goes wrong in 2 ways:
> you have not yet encountered N_FUN when you hit the N_SLINE
> stabs, so the offset is wrong, plus the value of N_SLINE is not
> relative as it's supposed to be.

   [ ... ]

> Anyone?

I think I've tracked this down in the gcc source tree.  Through a long
chain of embedded #includes starting in <config/sparc/netbsdelf.h>,
the Sparc gcc build eventually sees <config/svr4.h>, which has -- hidden
among a lot of other things -- these #defines:

   DBX_BLOCKS_FUNCTION_RELATIVE
   ASM_OUTPUT_SOURCE_LINE()      <--  makes the N_SLINEs relative
   DBX_FUNCTION_FIRST

I'm guessing that because the i386 ELF config was derived from the
Alpha config, the i386 gcc build never sees <config/svr4.h>, so it
never gets those #defines.


--Jim Howard  <jiho@mail.c-zone.net>