This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Line number problems with stabs and GCC 2.95.4 on FreeBSD/i386
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