Re: Line number problems with stabs and GCC 2.95.4 on FreeBSD/i386

[Mark Kettenis <kettenis@chello.nl>]

   Date: Mon, 12 Aug 2002 18:55:25 -0400
   From: Daniel Jacobowitz <drow@mvista.com>

   On Tue, Aug 13, 2002 at 12:38:39AM +0200, Mark Kettenis wrote:
   > I'm seeing quite a few regressions on FreeBSD/i386 with its default
   > compiler (which is based on GCC 2.95.4); the number of unexpected
   > failures went up from 94 to 142.  Unfortunately I did not update my
   > source tree for a while, so I had some trouble tracking down the cause
   > of these regeressions.  However, I'm pretty sure they're caused by an
   > interaction between Daniel's 2002-07-11 patch and incorrect debugging
   > info.  It looks as if my version of GCC emits two N_FUN stabs for the
   > beginning of a function.  This causes GDB to create two block
   > definitions: one that covers the entire function and one that has an
   > ending address equal to its starting address.  The last one is bogus,
   > and causes breakpoints to be set before the end of a function
   > prologue.  I suspect that Daniel's patch changes the ordering of the
   > block definitions, such that the bogus definition is used where the
   > correct one was used before.

   That's possible... I didn't really consider this case.  That's the
   third creative way I've seen GCC break debug info recently...  Does GCC
   even end the second N_FUN?

Nope.  We have two N_FUN's with call0a as its name and only a single
N_FUN with 0 as its name to end the function.  After that last N_FUN a
new function starts.

   Some compilers emit the ending N_FUN and others don't.  If we knew that
   the current compiler would, we could ignore the second N_FUN with the
   same name...

If you see an easy way to fix this, please go ahead, otherwise I'll try to come up with a patch myself.

Thanks,

Mark