This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH to buildsym.c


>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:

    Stan> Non-regression is good, but how is it that you're getting so
    Stan> many failures?  Current GDB on Linux should be at about 10
    Stan> fails, at least until very recently, when it went up to 30
    Stan> or so because some failing thread tests got counted instead
    Stan> of being skipped over.  178 is bad...

I dunno.  I did configure/make/make check on a RH 6.1 system using
/usr/bin/gcc as the compiler, and that's what happenned.  It could be
some kind of version skew with dejagnu, I suppose.  I'll look into it
a little bit.

    Stan> Different number means different source line, and a later
    Stan> source line is more likely to be inside the function, rather
    Stan> than on an empty line prior to the function or some such.
    Stan> It has the potential to be confusing to users, and also to
    Stan> GUIs, although it probably won't cause anything to roll over
    Stan> and die (unless DDD is more complicated than I think :-) ).

I hear what you're saying, but I'm not really buying it.  Basically,
you're trying to second-guess the compiler in the debugger; it seems
like pretty clear semantics to me to say last note wins.  

I understand that some compilers might do something bizarre (putting
the good note first, and then a note for an empty line after that).
If there really are such compilers, then we should maybe provide
work-arounds for that.  But, why do this to all compilers, even ones
that are doing this on purpose?

The current behavior is confusing in exactly the way you say; you get
to an inline function and wind up staring at a curly brace for the
caller:

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

This tends to have GDB at the opening curly brace for `g' when the
last line note is pointing at `i = 3'.  So, that's pretty strange.
Then, stepping ends you up at the closing curly brace for `g' without
ever ending up in `f'.

    Stan> Note that GDB has to work with different compilers, not just
    Stan> GCC, and so if you always have consistent handling of

I understand.

    Stan> multiple line notes, the testing results and user-visible
    Stan> behavior will be uniform across compilers and compiler
    Stan> versions.

I don't really see that, but I'll take your word for it.  Different
compilers are likely to emit line notes in lots of different ways.
Some may never emit duplicate line notes for the same PC.  But, it's
hard for me to imagine compiler people intentionally emitting a line
note correponding to the next instruction, then emitting another line
note *not* corresponding to that instruction, and then emitting the
instruction itself.  That's a little odd.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]