Re: Patch to speed up remote protocol

[Andrew Cagney <ac131313@cygnus.com>]

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