Re: Patch to speed up remote protocol

[jtc@redback.com (J.T. Conklin)]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> Attached is a patch that integrates your change into a general
Andrew> cleanup of ``P'' packet support code.  The patch adds the
Andrew> commands:
Andrew>
Andrew> 	set stub-supports-P-packet {supported,unsupported,auto}
Andrew>		show stub-supports-P-packet
Andrew>
Andrew> so explicit examination/control is also possible.  (I'm very
Andrew> interested in suggestions for a better variable name).  The
Andrew> bulk of the code is also generic so that it can be re-used by
Andrew> code detecting other optional packets.

I'm not sure I like the idea of setting GDB's support of the P packet
from the CLI.  If it can be autonegotiated successfully (which my
experience has shown to be true), there doesn't seem to be a need.  I
do agree that once a stub accepts 'P', it should be expected to always
support it within that debugging session.

As for names, it probably should have "remote" in the name to tie it
to the other remote protocol variables.  Perhaps:

	remote-stub-supports-P-packet
	remote-protocol-supports-P-packet
	remote-protocol-supports-register-set

But that's only if there really is a need for this variable.  We
shouldn't add knobs just because we can.

	--jtc

-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Wed Jul 07 17:53:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: Ian Lance Taylor <ian@airs.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: Patch to speed up remote protocol
Date: Wed, 07 Jul 1999 17:53:00 -0000
Message-id: <3783F623.8A26DA77@cygnus.com>
References: <19990702201648.32062.qmail@daffy.airs.com> <378338EC.C709D54@cygnus.com> <5md7y42ii0.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q3/msg00013.html
Content-length: 2424

"J.T. Conklin" wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> Andrew> Attached is a patch that integrates your change into a general
> Andrew> cleanup of ``P'' packet support code.  The patch adds the
> Andrew> commands:
> Andrew>
> Andrew>         set stub-supports-P-packet {supported,unsupported,auto}
> Andrew>         show stub-supports-P-packet
> Andrew>
> Andrew> so explicit examination/control is also possible.  (I'm very
> Andrew> interested in suggestions for a better variable name).  The
> Andrew> bulk of the code is also generic so that it can be re-used by
> Andrew> code detecting other optional packets.
> 
> I'm not sure I like the idea of setting GDB's support of the P packet
> from the CLI.  If it can be autonegotiated successfully (which my
> experience has shown to be true), there doesn't seem to be a need.  I
> do agree that once a stub accepts 'P', it should be expected to always
> support it within that debugging session.

FYI, auto-detect is the default.  Below is a typical interaction:
The initial ``set stub-supports-P-packet auto'' forces GDB back into its
default state and make things interesting.

(gdb) set stub-supports-P-packet auto
(gdb) show stub-supports-P-packet 
stub-supports-P-packet is auto-detected, currently unknown
(gdb) set $d1 = 2
Sending packet: $P1=02000000#40...Ack
Packet received: OK
[...]
(gdb) show stub-supports-P-packet 
stub-supports-P-packet is auto-detected, currently supported

> As for names, it probably should have "remote" in the name to tie it
> to the other remote protocol variables.  Perhaps:
> 
>         remote-stub-supports-P-packet
>         remote-protocol-supports-P-packet
>         remote-protocol-supports-register-set

remote-protocol-P-packet {supported,unsupported,auto}

plus  a ``{show,info} remote-protocol''.

> But that's only if there really is a need for this variable.  We
> shouldn't add knobs just because we can.

I think that there should at least be a display mechanism so that the
user can determine if the packet is being used.  The enable/disable is
there so that the user can control the probe.

While I don't expect the average engineer to be remotly interested in
this I would expect an engineer testing a stub to make use of it.

Rather than ``class_obscure'' the command should probably be
``class_maintenance''.

	enjoy,
		Andrew

(Hmm, things to do today - document the command).
From shebs@cygnus.com Wed Jul 07 18:17:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: eliz@delorie.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [eliz@is.elta.co.il: GDB: fine print in 387 info]
Date: Wed, 07 Jul 1999 18:17:00 -0000
Message-id: <199907080117.SAA16963@andros.cygnus.com>
References: <199907071328.JAA06637@indy.delorie.com>
X-SW-Source: 1999-q3/msg00014.html
Content-length: 1770

   Date: Wed, 7 Jul 1999 09:28:47 -0400 (EDT)
   From: Eli Zaretskii <eliz@delorie.com>

   IMHO, all the different versions of x87 support on the various platforms, 
   at least as far as GDB 4.18 sources go, are so close to one another that 
   they almost cry for unification.  I compared all of them at some point, 
   and they all seem like 95% cut-and-paste and 5% platform-dependent stuff.
   (And some of the platform-dependencies are just incompatibilities in the 
   order that the FP registers are enumerated in the header files.)

   I think it should be very easy to write a bunch of macros that would 
   hide any *real* platform-dependent aspects, like how you get the 
   registers from the debuggee, and use platform-independent code for 
   everything else.

I agree that we ought to be sharing some code here.  It's worth
considering whether this ought to be done with macros or with the new
architecture machinery; macros still make sense if the mods are purely
for native support, but you should use functions for anything that
might be used for cross-debugging.  Another way to look at it is -
suppose you were running a cross GDB hosted on djgpp targeting the
Hurd?  (Don't laugh, stranger configs have happened!)

   If people agree, the first step in the right direction would be to agree 
   on the layout of the information produced by "info float".  The new code 
   on i387-tdep.c is different from all the other platforms in this respect.

I can't think of a reason why users would want to have "info float"
display different things on different hosts, since it's supposed to
show info about the FPU, not the OS.  Unless someone can work up a
counterexample, let's define (and document) a single layout, and work
from that.

								Stan