Re: parcelling up struct gdbarch

[Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>]

On Mon, Jul 16, 2001 at 06:15:00PM -0400, Andrew Cagney wrote:
> 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.

OK, we're back to agreeing about everything.  That's good :)

> >> 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.

I'm still with you.  This makes sense.

> 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.

Right.  We don't have to worry currently about there being different
outgoing G's in gdbserver, but we do have to worry about incoming ones
in gdb from different remote stubs.  One thing at a time, though.

> > 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.

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

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. 

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.

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).

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.
 - Define, for a given gdbarch, how to parse the G/T/P packet register
numbering.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer