Re: new gdb remote packet type

Robert Picco
2004-05-12T18:59:00Z

Daniel Jacobowitz wrote:

On Wed, May 12, 2004 at 02:20:36PM -0400, Andrew Cagney wrote:

Yes, this is the key, use it conditionally, nice.

+ switch (remote_protocol_p.support)
+ {
+ case PACKET_DISABLE:
+ break;
+ case PACKET_ENABLE:
+ if (fetch_register_using_p (regnum))
+ return;
+ else
+ error ("Protocol error: p packet not recognized by stub");
+ case PACKET_SUPPORT_UNKNOWN:
+ if (fetch_register_using_p (regnum))
+ {
+ /* The stub recognized the 'p' packet. Remember this. */
+ remote_protocol_p.support = PACKET_ENABLE;
+ return;
+ }
+ else
+ {
+ /* The stub does not support the 'P' packet. Use 'G'
+ instead, and don't try using 'P' in the future (it
+ will just waste our time). */
+ remote_protocol_p.support = PACKET_DISABLE;
+ break;
+ }
+ }
sprintf (buf, "g");

This patch (if 'p' were implemented for gdbserver; I have this lying
around, as it happens) would make register fetches default to using
individual 'p' packets for every register; this would hurt latency, a
lot.
Robert, wouldn't it be good enough for you to work with
!reg->in_g_packet?

On IA64 the g-packet is too large for kernel debugging. How would you
suggest identifying registers that are in g-packet. Use another
protocol extension to see whether target wants to exclude registers from
g-packet? Another way would be to optionally enable the p-packet with a
"set-command". This p-packet causes very little latency on IA64 because
most register values retrieved come from RSE (register stack engine)
backing store memory.

thanks,

Bob