Re: parcelling up struct gdbarch

[Andrew Cagney <ac131313@cygnus.com>]

> 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