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
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Mark Kettenis <kettenis at gnu dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 12 Aug 2002 18:55:25 -0400
- Subject: Re: Line number problems with stabs and GCC 2.95.4 on FreeBSD/i386
- References: <200208122238.g7CMcdc5025808@elgar.kettenis.dyndns.org>
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?
>
> Here is part of the output from objdump --stabs for the funcargs test
> program from the testsuite:
>
> 48 FUN 0 78 0804846c 1404 call0a:F(0,1)
> 49 PSYM 0 78 00000008 1418 c:p(0,1)
> 50 PSYM 0 78 0000000c 1427 s:p(0,1)
> 51 PSYM 0 78 00000010 1436 i:p(0,1)
> 52 PSYM 0 78 00000014 1445 l:p(0,3)
> 53 SLINE 0 80 00000006 0
> 54 SLINE 0 81 00000013 0
> 55 SLINE 0 82 00000017 0
> 56 SLINE 0 83 0000001d 0
> 57 SLINE 0 84 00000024 0
> 58 SLINE 0 85 0000002b 0
> 59 FUN 0 78 0804846c 1404 call0a:F(0,1)
> 60 PSYM 0 78 00000008 1418 c:p(0,1)
> 61 PSYM 0 78 0000000c 1427 s:p(0,1)
> 62 PSYM 0 78 00000010 1436 i:p(0,1)
> 63 PSYM 0 78 00000014 1445 l:p(0,3)
> 64 LSYM 0 78 ffffffff 1454 c:(0,2)
> 65 LSYM 0 78 fffffffc 1462 s:(0,8)
> 66 FUN 0 0 0000002d 0
>
> Is there an easy way to fix this, or should we just consider this
> compiler to be broken?
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...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer