Re: PATCH to buildsym.c

[Mark Mitchell <mark@codesourcery.com>]

>>>>> "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
From jimb@cygnus.com Wed Dec 01 14:43:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: mainguen@gabin.frcl.bull.fr, gdb@sourceware.cygnus.com
Subject: Re: Gdb target for kdb
Date: Wed, 01 Dec 1999 14:43:00 -0000
Message-id: <npn1ru9t9y.fsf@zwingli.cygnus.com>
References: <199912010302.TAA17555@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00401.html
Content-length: 430

>    We intend to use gdb to debug a running Linux kernel connected
>    to another Linux box via an asynchronous line. For this purpose,
>    we are considering developping a new gdb target that interfaces
>    with kdb. Has anyone ever tried to develop such a kdb target
>    before ?
> 
> Not to my knowledge.  As Jim Blandy, you could pretend it's like a ROM
> monitor and do a backend that way.

But *only* if you're me.  :)
From jimb@cygnus.com Wed Dec 01 14:43:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: ST(i) and MMj
Date: Wed, 01 Dec 1999 14:43:00 -0000
Message-id: <npogca9tb8.fsf@zwingli.cygnus.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00400.html
Content-length: 942

> During that discussion I did agree that these registers should not be
> treated as separate, but it seems we meant different things.
> What I meant was that it is a Bad Idea to maintain separate data for
> each one of these sets.

Ah.  I see what you meant now.  Yes, we misunderstood each other.

> But I don't see why cannot GDB _think_ about %st(X) and %mmY as being
> separate registers while in reality they share the same data, if this
> sharing is concealed behind REGISTER_BYTE and REGISTER_RAW_SIZE (and
> possibly other functions/macros used to manipulate registers).  What
> are the specific problems with this scheme?

Grep the sources for NUM_REGS, and look for loops that traverse the
register set.  Prove to yourself that none of these loops will break
if register X aliases register Y.  Persuade yourself that nobody in
the future, innocent of the x86's sins, will write such a loop.

I tried, but I couldn't manage it.  :)
From jimb@cygnus.com Wed Dec 01 14:45:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: rok.papez@kiss.uni-lj.si
Cc: gdb@sourceware.cygnus.com, gnu-gdb-bug@moderators.isc.org
Subject: Re: Insight 19991116, gdbserver, fork() - always follows parent
Date: Wed, 01 Dec 1999 14:45:00 -0000
Message-id: <nppuwq9tia.fsf@zwingli.cygnus.com>
References: <99120112265800.00878@Strader.home>
X-SW-Source: 1999-q4/msg00402.html
Content-length: 546

I don't think follow-fork mode is implemented for Linux.

> 2.) Can insight and/or gdb finally work with LinuxThreads? What about
> gdbserver? Do new threads block when they get created ?

The snapshots should be able to debug applications that use
LinuxThreads.  Release 4.18 cannot.  Threads start running normally
when they are created. 

> 4.) Is it possible to compile into the programme a breakpoint (so when it is
> run I could attach to it) - if yes - how to make it work with gdbserver.

You can always do something like sleep (100000).
From shebs@cygnus.com Wed Dec 01 15:01:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: mark@codesourcery.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: PATCH to buildsym.c
Date: Wed, 01 Dec 1999 15:01:00 -0000
Message-id: <199912012301.PAA24624@andros.cygnus.com>
References: <19991201143603Z.mitchell@codesourcery.com>
X-SW-Source: 1999-q4/msg00403.html
Content-length: 2938

   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
From sbjohnson@ozemail.com.au Wed Dec 01 15:09:00 1999
From: Steven Johnson <sbjohnson@ozemail.com.au>
To: gdb@sourceware.cygnus.com
Subject: Standard GDB Remote Protocol
Date: Wed, 01 Dec 1999 15:09:00 -0000
Message-id: <3845AB0E.3795D99E@ozemail.com.au>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00404.html
Content-length: 997

I am about to write a GDB Remote Stub, and I want to use the standard
GDB Remote protocol for this.

Can anyone point me at the Protocol specification for this? Or doesn't
it exist?

Ive looked everywhere I can think of and can find nothing documented
about it, except references to the fact GDB has this standard Protocol.

I Know i'll get the answer "Use the Source". But that is hardly
appropriate for a Protocol. There are far more subtleties to Protocol
Design and Implementation than can usually be gleaned from anyone's
source code. 

If it doesn't exist, does anyone have any objections to a complete,
formal, Protocol specification for the GDB Remote Protocol being
created. (Note: here Im putting up my hand. If I have to reverse
engineer it from the code, Im going to document it for my benefit
anyway.)

If it does exist, is it up-to-date?

If I need to create one, what format should I create it in? (i.e.,
preferred document type).

Steven Johnson
Managing Director
Neurizon Pty Ltd
From jtc@redback.com Wed Dec 01 15:22:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Steven Johnson <sbjohnson@ozemail.com.au>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Wed, 01 Dec 1999 15:22:00 -0000
Message-id: <5md7sql00o.fsf@jtc.redbacknetworks.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au>
X-SW-Source: 1999-q4/msg00405.html
Content-length: 1287

>>>>> "Steven" == Steven Johnson <sbjohnson@ozemail.com.au> writes:
Steven> I am about to write a GDB Remote Stub, and I want to use the standard
Steven> GDB Remote protocol for this.
Steven>
Steven> Can anyone point me at the Protocol specification for this? Or doesn't
Steven> it exist?

I think the RDP specification still needs some work, but things are a
lot better than they were a even few months ago.  The spec has been
moved from comments in remote.c to the GDB manual.  Grab a snapshot
from sourceware to get the most recent copy.

I believe that Andrew Cagney had some changes in the queue, and I 
have some changes I was going to contribute once Andrew was done.

Steven> If it doesn't exist, does anyone have any objections to a complete,
Steven> formal, Protocol specification for the GDB Remote Protocol being
Steven> created. (Note: here Im putting up my hand. If I have to reverse
Steven> engineer it from the code, Im going to document it for my benefit
Steven> anyway.)

Since you're putting up your hand, would you be willing to review the
protocol spec and point out areas that are ambiguous, confusing, need
revising, etc?  I'm not going to point out what I think is wrong so I
won't bias you one way or the other.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From mark@codesourcery.com Wed Dec 01 15:31:00 1999
From: Mark Mitchell <mark@codesourcery.com>
To: shebs@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: PATCH to buildsym.c
Date: Wed, 01 Dec 1999 15:31:00 -0000
Message-id: <19991201153132K.mitchell@codesourcery.com>
References: <19991201143603Z.mitchell@codesourcery.com> <199912012301.PAA24624@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00407.html
Content-length: 2323

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

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

OK, I'll forward this to you privately if I can't see it right off.
Thanks!

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

We *already* specify this detail.  In particular, we specify that if a
compiler wants a debugger to show a particular line for a particular
instruction then it must emit a line note for that instruction and
*not* emit any line notes with higher numbered lines for that same
instruction.

We're changing the specification; on that I agree.  I'd just argue
that a) the old specification doesn't make much sense, and b) there
are no known examples of compilers purposefully using the old
specification (in particular, that emit line notes for lines that they
don't intend the instruction to correspond to, but only if the line
numbers are smaller than the correct line note.)

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

I'm sure lots of compilers do lots of weird things!  (I know GCC
does...)

I guess I'm arguing that since we know that GCC wants to do this, and
since GDB is primarily used with GCC, and since we seem to agree that
the change (abstractly) makes sense, and since we don't actually know
that anything will be broken, that we should go for the change.

If someone complains, then we can back out the patch and try to change
GCC, we can make GDB do different things depending on a user-provided
flag, etc.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
From kevinb@cygnus.com Wed Dec 01 15:31:00 1999
From: Kevin Buettner <kevinb@cygnus.com>
To: Steven Johnson <sbjohnson@ozemail.com.au>, gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Wed, 01 Dec 1999 15:31:00 -0000
Message-id: <991201233340.ZM24842@ocotillo.lan>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au> <sbjohnson@ozemail.com.au>
X-SW-Source: 1999-q4/msg00406.html
Content-length: 298

On Dec 2,  9:11am, Steven Johnson wrote:

> I am about to write a GDB Remote Stub, and I want to use the standard
> GDB Remote protocol for this.
> 
> Can anyone point me at the Protocol specification for this? Or doesn't
> it exist?

http://sourceware.cygnus.com/gdb/onlinedocs/gdb_14.html#IDX532
From qqi@world.std.com Wed Dec 01 15:38:00 1999
From: Quality Quorum <qqi@world.std.com>
To: gdb@sourceware.cygnus.com
Subject: bugs in remote.c
Date: Wed, 01 Dec 1999 15:38:00 -0000
Message-id: <Pine.SGI.3.95.991201173338.27503A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00408.html
Content-length: 1898

Hi, 


I found a few minor bugs in remote.c (gdb-19990519), I can provide 
fixes if necessary.

1. remote_write_bytes - either ':' has to be escaped too or 
   sequences have to be outlawed once and forever.

2. set_thread - ignores returned packet.

3. remote_get_threadinfo and remote_get_threadlist - assume that first
   two chars of the packet are fine - this one can really screw things up.

4. remote_open_1 - does not check for returned errors or non-supported 
   extended ops.

5. Inconsitent processing of returned errors: 
       a. Error is ignored by set_thread, remote_thread_alive,
          remote_get_threadinfo, remote_get_threadlist, 
          remote_current_thread, extended_remote_restart,
          remote_open_1, remote_fetch_registers, check_binary_download,
          remote_query.

       b. Error is considered worth a warning by get_offsets and
          remote_wait.

       c. Error is considered fatal by remote_detach,
          remote_fetch_registers, remote_store_registers,
          compare_sections_command.

       d. errno =  EIO is set by remote_write_bytes and remote_read_bytes.

       c. memory_error(EIO, startaddr) is called by remote_search.

6. Inconsistent processing of returned no-support status:
       a. compare_sections_command - consideres no support for the
          operation a fatal error.

       b. It is ignored by set_thread,  remote_thread_alive,
          remote_open_1, remote_write_bytes, remote_read_bytes,
          remote_store_registers, remote_fecth_registers.
          Naturally, some of these cases are improbable, however, 
          it does not mean that it shold not be checked to flag
          faulty stubs.

7. extended_remote_restart does not give target any time to do restart.

8. remote_fecth_registers is unique in a sense that it will keep trying
   until watchdog will be fired up.

Thanks,

Aleksey