Nasty bug - stabs vs -ffunction-sections

[Daniel Jacobowitz <drow at mvista dot com>]

I'm not sure if there's anything that can be done about this, but it's
really driving me insane...

Suppose we have a two trivial source files.  one.c contains just:
int one () { return 1; }

main.c contains just:
int one ();
int main () { return one (); }

Compile one.c with stabs debugging info and -ffunction-sections.  Compile
main.c with neither.  Link them, listing one.o before main.o.  We get this
wonderful behavior:

(gdb) p main
$1 = {<text variable, no debug info>} 0x4007b0 <main>
(gdb) b main
Breakpoint 1 at 0x400918: file one.c, line 1.

When we look main up in the symbol table, which is all we need for print, we
of course get the right address.  When we break we end up in a different
function entirely!  How'd that happen?

Well, let's take a look.  Here's the relevant stabs:

0      SO     0      0      00000000004007b0 7      /root/stab/
1      SO     0      0      00000000004007b0 1      one.c
23     FUN    0      1      00000000004008e0 921    one:F(0,1)
25     SOL    0      0      00000000004007b0 1      one.c
26     SLINE  0      1      0000000000000020 0      
27     FUN    0      0      0000000000000038 0      
28     SO     0      0      00000000004007b0 0      

So we only have debug info for one single object file.  It is clearly marked
to start and end at 4007b0, because its .text is of zero size.  But it has a
function whose address is higher.  Thus, the blockvector for one.o is marked
as encompassing a much larger area than it should - 0x4007b0 up to 0x4008e0. 
So find_pc_sect_line returns the best match for main (up at 0x4007b0,
conveniently) and decides it is on the first line of one.c, and sets the
breakpoint THERE.

I know DWARF2 has support for discontinuous address ranges.  How does GDB
internally hold that information (does it?)?  Is it worth hacking this
together for stabs?

This may seem like an academic problem, at first glance, by the way - Don't
Do That, or Don't Do That With Stabs - but stabs is still the default on
most Linux targets, and libstdc++.a is built from -ffunction-sections
objects.  This makes debugging sometimes really, really painful.  I
essentially can't trust break to do the right thing.  If we don't have
debugging info for a symbol, we should at least never call find_pc_sect_line
on its PC - don't we know that won't work?  At least usually?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer