More than one stabn for the same PC

More than one stabn for the same PC

[Mark Mitchell]

I've been looking at why debugging some C++ source wasn't going very
well, and here's what I've found.  GCC sometimes generates more than
one `.stabn' directive for the same PC, but with different line
numbers.  For example:

  .stabn <line number 9>
  .stabn <line number 5>
  <code here>

Because GDB does not use a stable sort when sorting line tables, this
the labeled code ends up reported as line number 9.  In fact, GDB
explicitly tries to pick the line-entry with the highest line-number;
see `compare_line_numbers' in buildsym.c.

That makes little sense to me; compilers ought to put these out in the
right order.  There is a comment in the code indicating that IBM XCOFF
gets this wrong, which seems to be the motivation for this.

So, I can see three possible fixes:

  o Change GCC to not generate the first entry.

    (Bad if you want to set a breakpoint on that line.)

  o Only do the sort for IBM XCOFF.

  o Change GDB to use a stable sort, i.e., change compare_line_numbers
    to sort by PC, but not perturb the order of elements with the 
    same PC.
 
I like the last option best.  Any objections to such a patch?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
From law@cygnus.com Mon Nov 29 17:29:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: gdb@sourceware.cygnus.com, gcc@gcc.gnu.org
Subject: Re: More than one stabn for the same PC 
Date: Mon, 29 Nov 1999 17:29:00 -0000
Message-id: <27496.943925188@upchuck>
References: <19991129165903H.mitchell@codesourcery.com>
X-SW-Source: 1999-q4/msg00360.html
Content-length: 1641

  In message < 19991129165903H.mitchell@codesourcery.com >you write:
  > 
  > I've been looking at why debugging some C++ source wasn't going very
  > well, and here's what I've found.  GCC sometimes generates more than
  > one `.stabn' directive for the same PC, but with different line
  > numbers.  For example:
  > 
  >   .stabn <line number 9>
  >   .stabn <line number 5>
  >   <code here>
  > 
  > Because GDB does not use a stable sort when sorting line tables, this
  > the labeled code ends up reported as line number 9.  In fact, GDB
  > explicitly tries to pick the line-entry with the highest line-number;
  > see `compare_line_numbers' in buildsym.c.
  > 
  > That makes little sense to me; compilers ought to put these out in the
  > right order.  There is a comment in the code indicating that IBM XCOFF
  > gets this wrong, which seems to be the motivation for this.
  > 
  > So, I can see three possible fixes:
  > 
  >   o Change GCC to not generate the first entry.
  > 
  >     (Bad if you want to set a breakpoint on that line.)
  > 
  >   o Only do the sort for IBM XCOFF.
  > 
  >   o Change GDB to use a stable sort, i.e., change compare_line_numbers
  >     to sort by PC, but not perturb the order of elements with the 
  >     same PC.
  >  
  > I like the last option best.  Any objections to such a patch?
Sounds reasonable to me.

Though I am curious, how does this happen?

I'd been thinking about cases where we'd want to emit multiple stabs with
different line numbers for the same pc value to describe certain optimizations
to the debugger but I wasn't aware that we already did this kind of stuff.

jeff

Re: More than one stabn for the same PC

[Mark Mitchell]

>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

    Jeffrey> Though I am curious, how does this happen?

We tend to do this with inlining.  (We're doing it more with
inlining-on-trees, but we used to do it anyhow.)  Consider:

  int i;
  inline int f () {  
    i = 3;
  }
  void g() {
    f();
  }

In `g' we first emit a line note for the line with the curly brace for
`g', then emit a line note for the line with `i = 3' in it.  I think
that's roughly the right thing, but the debugger gets confused.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
From law@cygnus.com Mon Nov 29 23:10:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: gdb@sourceware.cygnus.com, gcc@gcc.gnu.org
Subject: Re: More than one stabn for the same PC 
Date: Mon, 29 Nov 1999 23:10:00 -0000
Message-id: <28295.943945638@upchuck>
References: <19991129223717L.mitchell@codesourcery.com>
X-SW-Source: 1999-q4/msg00362.html
Content-length: 899

  In message < 19991129223717L.mitchell@codesourcery.com >you write:
  > >>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:
  > 
  >     Jeffrey> Though I am curious, how does this happen?
  > 
  > We tend to do this with inlining.  (We're doing it more with
  > inlining-on-trees, but we used to do it anyhow.)  Consider:
  > 
  >   int i;
  >   inline int f () {  
  >     i = 3;
  >   }
  >   void g() {
  >     f();
  >   }
  > 
  > In `g' we first emit a line note for the line with the curly brace for
  > `g', then emit a line note for the line with `i = 3' in it.  I think
  > that's roughly the right thing, but the debugger gets confused.
Looking at that I'd claim only one of the line notes should exist (probably
the one of the "i = 3" statement.

But it may be the case that our opinions about what constitutes sane debugging
information for inline function calls differs.
jeff

Re: More than one stabn for the same PC

[Mark Mitchell]

>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

    Jeffrey>   In message
    Jeffrey> < 19991129223717L.mitchell@codesourcery.com >you write:
    >> >>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:
    >> 
    Jeffrey> Though I am curious, how does this happen?
    >>  We tend to do this with inlining.  (We're doing it more with
    >> inlining-on-trees, but we used to do it anyhow.)  Consider:
    >> 
    >> int i; inline int f () { i = 3; } void g() { f(); }
    >> 
    >> In `g' we first emit a line note for the line with the curly
    >> brace for `g', then emit a line note for the line with `i = 3'
    >> in it.  I think that's roughly the right thing, but the
    >> debugger gets confused.

    Jeffrey> Looking at that I'd claim only one of the line notes
    Jeffrey> should exist (probably the one of the "i = 3" statement.

That's not entirely unreasonable.  But, I'd like to be able to say
`break at <line where call to f is>' and have something sensible
happen.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
From law@cygnus.com Mon Nov 29 23:29:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: gdb@sourceware.cygnus.com, gcc@gcc.gnu.org
Subject: Re: More than one stabn for the same PC 
Date: Mon, 29 Nov 1999 23:29:00 -0000
Message-id: <28424.943946812@upchuck>
References: <19991129232529S.mitchell@codesourcery.com>
X-SW-Source: 1999-q4/msg00364.html
Content-length: 1240

  In message < 19991129232529S.mitchell@codesourcery.com >you write:
  > >>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:
  > 
  >     Jeffrey>   In message
  >     Jeffrey> < 19991129223717L.mitchell@codesourcery.com >you write:
  >     >> >>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:
  >     >> 
  >     Jeffrey> Though I am curious, how does this happen?
  >     >>  We tend to do this with inlining.  (We're doing it more with
  >     >> inlining-on-trees, but we used to do it anyhow.)  Consider:
  >     >> 
  >     >> int i; inline int f () { i = 3; } void g() { f(); }
  >     >> 
  >     >> In `g' we first emit a line note for the line with the curly
  >     >> brace for `g', then emit a line note for the line with `i = 3'
  >     >> in it.  I think that's roughly the right thing, but the
  >     >> debugger gets confused.
  > 
  >     Jeffrey> Looking at that I'd claim only one of the line notes
  >     Jeffrey> should exist (probably the one of the "i = 3" statement.
  > 
  > That's not entirely unreasonable.  But, I'd like to be able to say
  > `break at <line where call to f is>' and have something sensible
  > happen.
Good point.  Considering that, both line notes are probably needed.

jeff

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