Re: Remote Target Protocol 'g' & 'P' Packets Broken for PowerPC!!!!!

[Andrew Cagney <ac131313 at cygnus dot com>]

[I pruned the CC line a little]

Nick Duffek wrote:
> 
> On 25-Oct-2000, Andrew Cagney wrote:
> 
> >Decoupling the way remote.c interprets RAW_REGISTER_BYTES from the way
> >it decodes G (et.al.) packets is on my (and probably a few others)
> >things todo today lists.
> 
> Is there a proposed solution on the table?
> 
> GDB could promise that the raw register array is packed in increasing
> register order (as in fact rs6000-tdep.c does).  But I think we can't get
> away from the stub needing knowledge of GDB's internal register numbering.

The only solution that would involve the register array would also
involve physical violence :-)

> A solution to _that_ would be to autogenerate GDB's and stubs' register
> numbers from a common source.  The same source could autogenerate the
> RAW_REGISTER_BYTES layout in the same way for both GDB and stubs, so it
> wouldn't be necessary to decouple RAW_REGISTER_BYTES from G et
> al. packets.

I think remote.c should have a separate independant mapping to/from G
packets and internal register buffers.  A target could provide a
default.  GDB could generate a default from stuff like
RAW_REGISTER_BYTES.  Main thing is that the user could change it at
runtime without affecting the other parts of the ISA/ABI.

The layout of the G packet could probably live in something like
include/gdb/g-<isa>.h.  It should definitly live somewhere.  FWIW, the
remote protocol spec does specify the layout of the G register for a few
targets.

The interaction might be something like:

	(gdb) show target g-packet-format
	0:4:r0,1:4:r1,2

the actual syntax gets nasty as it needs to be able to specify all sorts
of messy things like byte order, sign extension, combining registers in
strange ways or even where to simply skip bytes.  You'd also need to
define some sort of cannonical register naming scheme so that the above
spec was insulated from the vaguarities of vendor register names.

Steven Johnson wrote:

> There is no way to currently inform the stubs when architectures change.
> Realistically there needs to be. How about a "Set Arch" Message to the stub. It
> could be pretty big, it is only sent at startup and when the architecture
> changes. As far as I can tell the stub only needs to know about the
> construction and numbering used within the Register packets.

I don't know that a stub needs to know when an architecture changes. 
Given a stub is physically bound to a specific ISA the operation is
pretty meaningless.   What does make sense is for GDB to change the way
it is interpreting the raw information comming from the stub.

> This would then define to a stub what order registers are sent in for a 'g'
> response.
> 
> Stubs that don't understand this would ignore it and behave as they do now.
> 
> Stubs that do understand it would become multi-arch aware and the problem with
> 'g' would go away. Further, as long as the regname never changed after it was
> defined (and there is no realistic reason I can think of why it should) new
> registers could be defined and added and a stub would automatically handle it.
> Any register names it doesn't understand would be ignored and the stub could
> just return a default value for them.

I think this pushes unnecessary complexity down into the stub.  All a
stub should need worry about is how to construct a G packet and send it
back to GDB.  Its GDBs problem to sort out details like a user
specifying a MIPS3 ISA when the real target is MIPS4.

--

	enjoy,
		Andrew

PS: If anyting anoys me about the G packet it is that it is not target
byte order independant.  The G packet changes depending on the targets
byte order (ulgh :-).