Re: PATCH to buildsym.c

[Stan Shebs <shebs at cygnus dot com>]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Wed, 01 Dec 1999 14:36:03 -0800

   >>>>> "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.

If you point me at a gdb.{sum,log}, I could do a quick analysis.

       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.  

Indeed it is clear; my question is whether we can get away with
specifying a detail of the compiler output that has not been specified
previously.  Your proposal is basically to require that compilers
issue line notes in a specific order.  While this is attractive for
improving debug of inlined functions, it is still a change to the spec
of the compiler/debugger interface, and it's a change to be more
restrictive.  So we need to understand if there are any compatibility
pitfalls.

Also, the change history suggests that when this code was last tinkered
with, in 1993, Kingdon was unsure what to do here, and when Kingdon
doesn't know, I tremble... :-)

       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.

Yeah, well, some versions of Sun's compiler have been notable for
oddity of debug output.  The stabs manual mentions some amusing
cases, although reassuringly, none of them involve line numbers.

								Stan