From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: parcelling up struct gdbarch Date: Thu, 19 Jul 2001 07:51:00 -0000 Message-id: <3B56F3D4.5000300@cygnus.com> References: <3B533AAD.1060300@cygnus.com> <20010716130559.B25488@nevyn.them.org> <3B536764.1000508@cygnus.com> <20010716154904.A8712@nevyn.them.org> <3B547A08.2030403@cygnus.com> <20010717110305.A18932@nevyn.them.org> <3B5485C5.2010007@cygnus.com> <20010718132140.A2937@nevyn.them.org> <3B5675BA.4010403@cygnus.com> <20010718232242.A24417@nevyn.them.org> <20010719002318.A2129@nevyn.them.org> X-SW-Source: 2001-07/msg00276.html > > And it works. I currently move handling of the 'g' and 'G' packets off > into the low-* file, which makes drastically more sense anyway. The > code for prepare_resume_reply still needs to be handled, but the > changes are trivial once the rest is in place. I'm sure it will work. > In remote.c, I add a 'qRegisters' packet with the reply > 'qRegisters:IDENTIFIER', where IDENTIFIER is a (hex-encoded) defined > name. It defines a register numbering, which remote.c takes care to > use when talking to the target if one is available. The client-side > changes are finished and I'll post them in the morning when I'm awake > enough to write a proper changelog. Just a heads up. This ``IDENTIFIER'' has consequences. The mechanics are the easy bit. It is sorting out things like how to consitently define ``IDENTIFER'' that isn't. Andrew