[RFC] Re: Nasty bug - stabs vs -ffunction-sections

[Daniel Jacobowitz <drow at mvista dot com>]

I received the following patch from Peter Schauer
<Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE>.  Does anyone have a
comment?  It doesn't seem to me that grubbing through the symtab for
line numbers is likely to work if we don't know what function we're in.

*** ./symtab.c.orig	Sun Jul 29 10:49:00 2001
--- ./symtab.c	Sun Jul 29 10:58:55 2001
***************
*** 1604,1609 ****
--- 1606,1619 ----
  
    INIT_SAL (&val);		/* initialize to zeroes */
  
+   /* Don't even think about line numbers if we can't find a function
+      symbol for PC.  */
+   if (find_pc_function (pc) == NULL)
+     {
+       val.pc = pc;
+       return val;
+     }
+ 
    if (notcurrent)
      pc -= 1;
  

> 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

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