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

[Daniel Jacobowitz <drow at mvista dot 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?

> 
> 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