More than one stabn for the same PC

[Timothy J. Wood]

  These extra stabs can actually allow you to do something more interesting 
that simply setting breakpoints, though.  Say I use the example:

int i;

static inline void f()
{
  i = 3;
}

static inline void g()
{
  f();
}

void h()
{
  g();
}


  Then on MacOS X Server PPC (which uses a mangled version of 2.7.2.1, but 
this should be applicable to other platforms), I get the following (cc 
-static -O2 -g -S test.c)


.globl _h
_h:
        .stabd 68,0,15
        stwu r1,-32(r1)
        .stabd 68,0,16
LBB2:
LBB3:
        .stabd 68,0,11
LBB4:
LBB5:
        .stabd 68,0,6
        addis r9,0,ha16(_i)
        addi r9,r9,lo16(_i)
        li r0,3
        stw r0,0(r9)
        .stabd 68,0,7
LBE5:
        .stabd 68,0,12
LBE4:
LBE3:
        .stabd 68,0,17
LBE2:
        addi r1,r1,32
        blr
.stabs "h:F19",36,0,15,_h
.stabn 192,0,0,LBB2
.stabn 192,0,0,LBB3
.stabn 192,0,0,LBB4
.stabn 192,0,0,LBB5
.stabn 224,0,0,LBE5
.stabn 224,0,0,LBE4
.stabn 224,0,0,LBE3
.stabn 224,0,0,LBE2


  If my program is stopped at the 'li r0,3' (i.e, the 'i = 3') line, then 
the debugger could construct a pseudo BACKTRACE from that point by searching 
backwards looking at the line numbers for the N_LBRAC stabs.  The debugger 
could then have the notion that the code on that line had a backtrace like:


  ??   test.c  line 6  (inlined)
  ??   test.c, line 11 (inlined)
  h()  test.c, line 16

  For non-static inlines, it could potentially track down the name of the 
function that was inlined.  For inlines included from other files, it could 
use the N_SOL stabs to find the right file name.


-tim