Re: PATCH to buildsym.c

Re: PATCH to buildsym.c

[Jim Blandy]

I'm sympathetic to the concerns about possibly breaking other systems,
but I don't think it's good to put off changes with known benefits
just because we're not sure whether it might break something, though
we're not sure what.  It's sort of paralyzing to approach things that
way.

I think we should make the change, and comment the code with an
explanation of why it should be this way.  If it does break something
else, at least we can make a decision in the presence of data.

In any case, as the symtab maintainer, I think the change is okay.
When Stan turns out to be right, and the next Mars Lander mission
fails because they can't set a breakpoint where they need to, I'll
throw myself on my sword, okay?

Mark, you offered to commit the change, but do you really have commit
access to GDB?  I'm so out of touch...
From mark@codesourcery.com Fri Dec 03 10:03:00 1999
From: Mark Mitchell <mark@codesourcery.com>
To: jimb@cygnus.com
Cc: shebs@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: PATCH to buildsym.c
Date: Fri, 03 Dec 1999 10:03:00 -0000
Message-id: <19991203100251E.mitchell@codesourcery.com>
References: <199912012043.MAA07059@andros.cygnus.com> <npvh6g7y0y.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00438.html
Content-length: 896

>>>>> "Jim" == Jim Blandy <jimb@cygnus.com> writes:

    Jim> In any case, as the symtab maintainer, I think the change is
    Jim> okay.  When Stan turns out to be right, and the next Mars
    Jim> Lander mission fails because they can't set a breakpoint
    Jim> where they need to, I'll throw myself on my sword, okay?

And I'll hurl myself upon the still-exposed, but now-bloody point.

    Jim> Mark, you offered to commit the change, but do you really
    Jim> have commit access to GDB?  I'm so out of touch...

No, I don't.  I had thought that I had write access (if properly
approved) to all of the sourceware archives, but Tom Tromey explained
(privately) that the official GDB is still maintained inside Cygnus.
So, I'm obliged to make use of your services.

Thanks!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
From shebs@cygnus.com Fri Dec 03 10:57:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: jimb@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: GDB i386 ports are now all cleaned up
Date: Fri, 03 Dec 1999 10:57:00 -0000
Message-id: <199912031857.KAA05260@andros.cygnus.com>
References: <npwvqy9ybx.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00439.html
Content-length: 711

   From: Jim Blandy <jimb@cygnus.com>
   Date: 01 Dec 1999 15:54:10 -0500

   Well, at least their register maps are cleaned up, anyway.

   Chris Faylor just finished updating the Cygwin port, so now all the
   x86 ports of GDB that are in active use rely on a single common base
   for their register definitions, provided by tm-i386.h.  This makes it
   a bit easier to write code which benefits all the x86 ports.  Check
   out http://sourceware.cygnus.com/gdb/papers/linux/i386-includes.png
   to see the current state of affairs.

   Thanks to everyone for helping clean up the mess!

And thank *you* for coordinating things!  This will help make the next
release of GDB the best one ever!

								Stan

Re: PATCH to buildsym.c

[Stan Shebs]

   From: Jim Blandy <jimb@cygnus.com>
   Date: 03 Dec 1999 12:08:13 -0500

   I'm sympathetic to the concerns about possibly breaking other systems,
   but I don't think it's good to put off changes with known benefits
   just because we're not sure whether it might break something, though
   we're not sure what.  It's sort of paralyzing to approach things that
   way.

Generally you want to adjust your risk-taking to the situation.  A
speedup in platform-specific code is almost always safe, a change in
the compiler/debugger interface has more serious consequences.  It's
been a while now, so most people have probably forgotten, but when we
changed some stab values to be assumed to be function-relative rather
than absolute, it took two years for all the aftereffects to settle
out - there were far more stabs readers in the world than we realized!

   I think we should make the change, and comment the code with an
   explanation of why it should be this way.  If it does break something
   else, at least we can make a decision in the presence of data.

Sure, I can go along with that.

   In any case, as the symtab maintainer, I think the change is okay.
   When Stan turns out to be right, and the next Mars Lander mission
   fails because they can't set a breakpoint where they need to, I'll
   throw myself on my sword, okay?

:-) Boy, how must it feel to know your mistake resulted in the loss
of a billion-dollar space probe - death might seem preferable to going
back in to work the next day...

								Stan
From jimb@cygnus.com Fri Dec 03 14:38:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: 64-bit stabs?
Date: Fri, 03 Dec 1999 14:38:00 -0000
Message-id: <npso1j8xbi.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00441.html
Content-length: 118

Have we ever used STABS in 64-bit executables before?  How large is
the value field of a stab in a 64-bit executable?
From ac131313@cygnus.com Fri Dec 03 23:10:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Quality Quorum <qqi@world.std.com>
Cc: gdb@sourceware.cygnus.com, Stan Shebs <shebs@cygnus.com>
Subject: Re: bugs in remote.c
Date: Fri, 03 Dec 1999 23:10:00 -0000
Message-id: <3848BE1F.DA83579B@cygnus.com>
References: <Pine.SGI.3.95.991201173338.27503A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00442.html
Content-length: 2415

Quality Quorum wrote:
> 
> Hi,
> 
> I found a few minor bugs in remote.c (gdb-19990519), I can provide
> fixes if necessary.

Patches are always useful (got the GPL assignment in place? :-).

I've also got some questions.  I'm lost by some of the points.

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

I'm confused.  Can you explain exactly what the problem is?

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

Outch! Yes.

The target can make GDB read uninitialized memory from the top-of-stack
:-(.  Could you please submit a patch for this?

Stan, you may want to keep an eye out for this sort of thing.


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

In the case of the extended op, it isn't possible to verify the
response.  See the protocol specification for details of the problem.

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

Can you expand on these  I'm unclear as to which errors you're refering
to and what processing should be present.  If you've a patch I'd be very
interested.

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

One note of caution. GDB is generally slack when it comes to verifying
responses.  This is because the original spec (have a look in any
*-stub.c file) didn't define these and where defined most
implementations ignored them. The general approach has been to verify
just sufficient to be fairly sure that the target is still ok.

	enjoy,
		Andrew
From qqi@world.std.com Sat Dec 04 04:27:00 1999
From: Quality Quorum <qqi@world.std.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com, Stan Shebs <shebs@cygnus.com>
Subject: Re: bugs in remote.c
Date: Sat, 04 Dec 1999 04:27:00 -0000
Message-id: <Pine.SGI.3.95.991204071415.15045A-100000@world.std.com>
References: <3848BE1F.DA83579B@cygnus.com>
X-SW-Source: 1999-q4/msg00443.html
Content-length: 2501

On Sat, 4 Dec 1999, Andrew Cagney wrote:

> Quality Quorum wrote:
> > 
> > Hi,
> > 
> > I found a few minor bugs in remote.c (gdb-19990519), I can provide
> > fixes if necessary.
> 
> Patches are always useful (got the GPL assignment in place? :-).

I will do it shortly, is it OK to do it against 4.18 ?

> 
> I've also got some questions.  I'm lost by some of the points.
> 
> > 1. remote_write_bytes - either ':' has to be escaped too or
> >    sequences have to be outlawed once and forever.
> 
> I'm confused.  Can you explain exactly what the problem is?

Let us suppose you got a packet  "$Xab:cd....", does it
contain sequence or not ?

> > 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.
> 
> Can you expand on these  I'm unclear as to which errors you're refering
> to and what processing should be present.  If you've a patch I'd be very
> interested.

Once you got "$E..." it is either memory access error (which is 
processed properly in my view) or an indication of something 
truly bad which is fatal in my view.

> 
> > 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.
> > 
> 
> One note of caution. GDB is generally slack when it comes to verifying
> responses.  This is because the original spec (have a look in any
> *-stub.c file) didn't define these and where defined most
> implementations ignored them. The general approach has been to verify
> just sufficient to be fairly sure that the target is still ok.

I looked through the stubs and it seems to me every stab does a pretty 
good job of returning "$#00" on anything it does not understands. 
IMHO, there is no point in ignoring no-support status. I will submit
patch which will clarify the issue.

> 
> 	enjoy,
> 		Andrew
> 

Thanks,

Aleksey

Re: PATCH to buildsym.c

[Todd Whitesel]

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

Compiler people vary widely in their committment to good debug info output.

I'll spare you the details, but over the years I've learned to be very
cynical about this. Attribute preservation in the face of optimization is
actually a quite tough problem, whether it's for debug info or volatile
qualifiers or something else. Many compiler folks I have dealt with just
seem to stick their heads in the sand and wish the whole issue would simply
evaporate, but of course it can't.

Having worked on compilers a bit myself, I've seen how the preservation
code can explode the complexity of many algorithms. It may be hard, but
it's still necessary. I consider this to be more of a "grand challenge"
problem worthy of study than the futile ILP stuff dictated by Merced.

-- 
Todd Whitesel
toddpw @ windriver.com
From qqi@world.std.com Mon Dec 06 16:54:00 1999
From: Quality Quorum <qqi@world.std.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: bugs in remote.c
Date: Mon, 06 Dec 1999 16:54:00 -0000
Message-id: <Pine.SGI.3.95.991206195415.3408A-100000@world.std.com>
References: <199912062200.OAA24749@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00461.html
Content-length: 2089

On Mon, 6 Dec 1999, Stan Shebs wrote:

> 
>    Date: Sun, 5 Dec 1999 14:17:31 -0500 (EST)
>    From: Quality Quorum <qqi@world.std.com>
> 
>    It seems to me that minimal requirements to a stub should be:
> 
>    1. Return empty on everything it does not understand.
>    2. Does not change its mind about understanding something while
>       in the middle of operation. E.g. if it supports extended ops 
>       should also support restart.
>    3. Return 'ENN' if (a) fatal error occured or (b) memory error 
>       occured.
> 
>    It seems to me that it is an absolute minimum set of requirements,
>    which will allow to complex stuff like queries to work properly.
> 
> In general, that is what we've always expected from stubs.  The
> "empty response to unsupported packet" rule, for instance, has been
> written down for a long time.
> 
>    It seems to me that people with uncompliant stubs should keep
>    using gdb-4.18 or earlier, which are pretty decent debuggers
>    anyway. Also, it seems like really simple thing to add 
>    something like 'old-remote' target which will lack new and shining
>    stuff (e.g. extended ops, single register assignments and queries) but
>    will be more tolerant towards old screwed up stubs.
> 
> There are a *lot* of stubs in ROM and out in the field; so I'd be very
> reluctant to decree that they are no longer to be supported, even by
> using a different target name.

Let us give a different target name for a new thing.

>  Instead, we should continue to tighten
> up the new standard, but allow exceptions if truly necessary, on a
> case-by-case basis.  For instance, a couple letters can never be used
> for packet type because somebody already used them.  That's OK, we
> have lots more letters available to us, and they're now explicitly
> stated as being reserved for future use.
> 
> Actually, it would be interesting to find out about the lowest (sea
> floor?) and highest uses of GDB stubs (Mars?), smallest computer, most
> hostile environment, etc.  Who's got the best story?
> 
> 								Stan
> 

Thanks,

Aleksey

Re: PATCH to buildsym.c

[Mark Mitchell]

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