From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: Andrew Cagney Cc: Robert Picco , gdb-patches@sources.redhat.com Subject: Re: new gdb remote packet type Date: Wed, 12 May 2004 20:53:00 -0000 Message-id: <20040512205337.GA3728@nevyn.them.org> 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> <40A279AF.30603@gnu.org> X-SW-Source: 2004-05/msg00384.html On Wed, May 12, 2004 at 03:23:27PM -0400, Andrew Cagney wrote: > > >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. > > That isn't true. The T packet should have previously returned all the > important registers (and is needed anyway to make single step fast). > This "p" would just fill in the gaps. > > If after this we still have problems, we can investigate transfering > registers in bigger chunks using qPart: (it was concluded that, > for the moment, it is too bigger sledge hammer for this simple nut). Sure enough, I'm mistaken. There's no target_fetch_registers (-1) in the core code any more, although I think there used to be; just in various native and corefile code. So "p" should work OK. > >Robert, wouldn't it be good enough for you to work with > >!reg->in_g_packet? > > The original problem is that all registers are in the g-packet and that > it was too big. Ah, I see what's going on (though not why it "doesn't work" - I can see it would be hideously slow though. -- Daniel Jacobowitz