Re: parcelling up struct gdbarch

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

On Mon, Jul 16, 2001 at 03:04:13PM -0400, Andrew Cagney wrote:
> 
> > legacy_breakpoint_from_pc, default_memory_insert_breakpoint, etc.  It
> > also brings in gdb_stdout, which means we need main.o.  It's hopeless.
> 
> 
> If GDBserver is going to be come more tightly integrated into GDB then 
> it is going to need to pick up some baggage like ui-file.

It's my opinion that that's the wrong way to do it.  We should
compartmentalize interface further away from the parts gdbserver needs. 
If necessary some functions can have separate minimal implementations
in gdbserver.

> >> The gdbserver code that refers to those macros has, has a result of the 
> >> above revalation, become wrong.  The nat code, in general, should refer 
> >> to nat, raw or G register numbering and not cooked registers.  When it 
> >> comes to the registers to pass back with the T packet, I think it should 
> >> be given an explicit list.
> > 
> > 
> > It doesn't refer to those register numbers when generating a G packet
> > at all.  It just passes the entire buffer.  The only issue in creation
> > of G packets is REGISTER_BYTES.
> 
> 
> Hmm, by ``G packet registers'' I'm refering to how registers are laid 
> out for a G packet.  When the stub creates a T packet that includes 
> expedited registers, those registers should be identified using their 
> G-packet numbering.

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.

> > It's the T packet that uses them, currently.  outreg() sends
> > regno:value pairs; regno is a cooked regno.  This is the only use of
> > REGISTER_BYTE or REGISTER_RAW_SIZE outside of a low-* file.
> 
> 
> And it's wrong.
> 
> Per other e-mail, gdbserver can have either:
> 
> 	o	*-nat.c map system registers onto
> 		raw register and then gdbserver
> 		map raw registers onto G-registers
> 
> 	o	*-nat.c map system registers onto
> 		G-registers directly (when compiled
> 		for GDBSERVER, say).
> 
> 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.

> > What would you say to providing this list in the form of (cooked regno,
> > raw offset, raw size) in the nm.h file?  It's very fragile, but without
> > protocol changes it's the best we can do right now.
> 
> 
> 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
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.

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