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

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

[Mark Kettenis]

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.

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?

Mark

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

[Daniel Jacobowitz]

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

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

[Mark Kettenis]

   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

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

[Mark Kettenis]

   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?

Looks like this problem is caused by a patch made by the FreeBSD folks
to the GCC in the FreeBSD source tree.  Since the braindamage seems to
be too big to work around in GDB I'll try to get FreeBSD's GCC fixed instead.

Sorry to have bothered you,

Mark