From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Picco To: Daniel Jacobowitz Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: new gdb remote packet type Date: Wed, 12 May 2004 22:16:00 -0000 Message-id: <40A2A39A.40208@hp.com> References: <4087E8C0.30806@hp.com> <4087EE4B.4010805@gnu.org> <40912015.7070902@hp.com> <40928D64.8010209@gnu.org> <4097D9DE.2030004@hp.com> <40993C21.1040500@gnu.org> <409A95AB.6020101@hp.com> <40A26AF4.4050001@gnu.org> <20040512183055.GA32460@nevyn.them.org> <40A27584.7090200@hp.com> <20040512205512.GB3728@nevyn.them.org> X-SW-Source: 2004-05/msg00390.html Daniel Jacobowitz wrote: On Wed, May 12, 2004 at 03:05:40PM -0400, Robert Picco wrote: 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. The latency I was worried about was round trip time - if we have to request a half-dozen out of a hundred registers, then this will probably take longer than a whole g packet would, because of waiting for each side to process the conversation. I guess we'll ignore it for now and investigate smaller regsets later with qPart. Ah. I see. Would you like to share your gdbserver "p-packet" code with me? There's no point in me reinventing what you have already done. I've looked at the gdbserver code some. The 'P' packet isn't being recognized. If the 'P' packet isn't supported, then do we want to support the 'p' packet in gdbserver? thanks, Bob