This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: PATCH to buildsym.c
- To: mark at codesourcery dot com
- Subject: Re: PATCH to buildsym.c
- From: Stan Shebs <shebs at cygnus dot com>
- Date: Wed, 1 Dec 1999 15:01:39 -0800
- CC: gdb at sourceware dot 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