Re: PATCH to buildsym.c

[Stan Shebs <shebs at cygnus dot com>]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Wed, 01 Dec 1999 13:51:15 -0800

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

       Stan> I haven't been following the discussion as closely as I'd
       Stan> like, but I'm concerned that this change will break some
       Stan> expected behavior.  How do the test results look before and
       Stan> after?  How about with other than the latest GCC?

   I get the same 178 failures with or without the change using EGCS 1.0.1.

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

   I believe that GCC emitted this kind of thing for some time, but has
   started to do so more frequently lately.

   What expected behavior could be broken?  The only difference will be
   that the debugger might show a different line number if there are two
   line notes for the same PC.  What rationale justifies picking the one
   with the highest number rather than the one the compiler emitted last?

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

Note that GDB has to work with different compilers, not just GCC, and
so if you always have consistent handling of multiple line notes, the
testing results and user-visible behavior will be uniform across
compilers and compiler versions.

								Stan