new gdb remote packet type
Robert Picco
Robert.Picco@hp.com
Wed May 12 18:59:00 GMT 2004
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
More information about the Gdb-patches
mailing list