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

[Mark Kettenis <kettenis at gnu dot org>]

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