Re: new gdb remote packet type

[Robert Picco <Robert.Picco@hp.com>]

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