Re: parcelling up struct gdbarch

[Andrew Cagney <ac131313@cygnus.com>]

> The definition of the remote protocol, such as it is, says:
> 
>    In general, the raw representation is determined by the
> architecture, or GDB's interface to the architecture, while the virtual
> representation can be chosen for GDB's convenience.  GDB's register
> file, `registers', holds the register contents in raw format, and the
> GDB remote protocol transmits register values in raw format.
> 
> The G packet is defined as the format of the register cache.
> 
> Are you saying you want to change that?  How do you envision doing this
> without slaughtering the protocol?  That's where I'm confused.


The documentation reflects the current state of play, good^D^D^D or^D^D 
bad.  If you alter the layout of the register cache, you change the 
remote protocol.  Hmm, something wrong here.


>> The thing the *-nat and GDB server code shouldn't be doing is trying to 
>> map registers onto internal-to-GDB cooked registers.  (Keep in mind that 
>> the existing code base largely doesn't follow this :-( ).
> 
> Largely?  I'd say completely.


remote-sim.h has a mapping mechanism - it needs to map between GDB's 
internal register layout and that of the simulator.

Originally GDB's register cache (and hence the G-packet) was defined by 
the layout of the raw register bytes returned by ptrace() fortunatly 
*-nat.c files are at least unpacking those structure and using 
supply_register() to fill the register cache.


>> No, something completly outside of *.h that defines the G-packet layout 
>> (and possibly the register cache) and how *-nat.c should map registers 
>> onto it.
> 
> 
> I don't see the need for this profusion of register formats.  We've got
> too many already.  Yes, the existing MIPS architectures all have


You've lost me here.  The reason for separating out and more formally 
specifying the G-packet layout is so that it is set in stone.  No matter 
what someone does to the register cache, or any other part of GDB, the 
remote protocol continues to work.

In the case of MIPS, this means that GDB will need to publish several 
different G-packets and support all of them.  Such is life, if long ago 
someone had thought to separate out and publish the G-packet layouts 
then we wouldn't be in this mess.

Regarding the register cache (or GDB's RAW registers).  A *-nat.c 
something needs to correctly map between raw registers (as stored in the 
register cache) and ptrace/... registers as supplied by the OS.  By 
formalizing the raw register layout, that process should be simplified. 
  (See posts from earlier this year).

> separate G packet formats; but what can be done about that, and what
> needs to be?  GDB and gdbserver need to agree about this anyway,
> because it also affects things like which registers can successfully be
> set.
> 
> If anything, gdbserver should just be sending the registers in the same
> format that *-nat.c gets them, and then they should pass through the
> same conversion function.  I'm thinking gdb_gregset_t here and
> REGISTER_U_ADDR here.  But again, I don't see what to do without
> introducing a new packet type; and most architectures are not ready to
> parse a gdb_gregset_t in a cross-debugger.


I think we're getting somewhere :-)

I take it you're proposing that G-packet layout would be defined by what 
was returned in the ptrace() buffer.  Don't forget that every OS has a 
different buffer layout - that means that they all have different 
G-packet layouts (I thought we already had too many).  This also means 
that you need to be very careful to not change anything that affects 
that packet for a given target.

It would give the layering:

   ptrace buffer
     |
   no-change (by gdbserver)
     |
   g register layout (including T registers)
     |
   remote.c uses some sort of unpack code
     |  (possibly in nat.c, this was always
     |   going to be needed and is clearly
     |   mising at present)
     |
   raw register layout
     .
     .

Remember that for the T and [Pp] packets to work, gdbserver will need to 
know something about that buffer.

	Andrew