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: Tue, 17 Jul 2001 10:46:00 -0000 Message-id: <3B547A08.2030403@cygnus.com> References: <20010713001635.A19524@nevyn.them.org> <3B4F4D7F.6010201@cygnus.com> <20010713145356.A4898@nevyn.them.org> <3B506250.5080502@cygnus.com> <20010716112536.A19620@nevyn.them.org> <3B533AAD.1060300@cygnus.com> <20010716130559.B25488@nevyn.them.org> <3B536764.1000508@cygnus.com> <20010716154904.A8712@nevyn.them.org> X-SW-Source: 2001-07/msg00212.html > I think that's acceptable. The ptrace buffer meets some important > criteria: > - it rarely changes, except perhaps to grow (SSE, altivec). > - We already have to have code to parse it (in order for native gdb > to work) although this code may not be easily cross-friendly See other e-mail about signals/events having similar problems. > On the other hand, we've already GOT a de-facto format, and there are > debugging stubs out there that use it. This is where I'm confused. For MIPS we've defacto standards, lots of defacto standards :-) > What can we do to make it more obvious what format of G packet is being > sent? My instinct tells me to define the format of the packet, with a > version number and architecture string, and define a message from > gdbserver to gdb which contains both arch and version. This would be > useful for lots of other reasons too. Then if we see a G packet after > receiving that version notification, we can just pass it off to the > appropriate handler and be done. There are two cases: o GDB talking to one of those old stubs o GDB talking to a not yet written stub Even if someone did magic a new stub, GDB would still need to be able to talk to all the old stubs. Consequently, I'll only look at old stubs. With that in mind, I think, the G-packet <-> raw register mapping shouldn't be per gdbarch hard-coded but instead driven by something the user can specify on the command line. Short term, some sort of hardwiring might be accepted. Refering back to that figure: G-packet registers | raw registers | cooked registers If raw registers are given names independant of the user visible cooked registers then, something as silly as: 0:gpr0,4;1:gpr1,4;4;3:spr0;8;4;... would even work. > That same version notification can define a format for the T and P > packets also (of course gdbserver doesn't even support P packets yet, > as far as I see). John S. Kallal submitted a patch: ``[PATCH] Add remote P packet ...'' It needed to be split in two (cleanup VS change) and along with a few other tweeks. > Rather than letting ideas continue to bounce around, how's this: > - add an arch request to GDB and gdbserver. It seems more natural for > gdbserver to send its architecture and gdb acknowledge if it > understands; but a qArch would work too. See the multi-arch white paper. It notes both alternatives. qArch is probably more inline with other parts of the protocol. I don't think you need to do this to solve the current problems. > - Define, for a given gdbarch, how to parse the G/T/P packet register > numbering. As I noted above, a given gdbarch might have _several_ G-packet <-> raw register mappings Andrew