Re: gdbserver, remote serial protocol and endian issues

[Andrew Cagney <ac131313 at cygnus dot com>]

> On Mon, Apr 08, 2002 at 04:33:01PM +0100, Paul Bartlett wrote:
> 
>> Hi Daniel,
>> 
> 
>> > I don't agree.  Target registers are in 
>> > target-endianness when you read them off 
>> > the stack; they should be in target endianness 
>> > in memory.  GDB has 'set endian little' and 
>> > 'set endian big', and the stub should just pass 
>> > them along however it gets them.  gdbserver is 
>> > also meant to run in a native configuration, 
>> > where compile-time checks can tell you the 
>> > endianness.
> 
>> 
>> Well, maybe I'm guilty of not considering the
>> general case - haven't thought it through yet.
> 
> 
> As soon as you try looking through stack frames, you realize that
> keeping registers in target byte order is a lot simpler for the rest of
> GDB.

Hardware registers are byte-order netural.  It is the way they are 
``spilt'' into memory that is not.  The best guess at an intpretation of 
the remote protocol's G packet format is that it transfers ``spilt'' 
registers.

As for memory transfers.  They are currently ``byte order netural'' (1)(2).

Anyway, two references:

http://sources.redhat.com/gdb/papers/multi-arch/real-multi-arch/index.html#SEC40
http://sources.redhat.com/gdb/bugs/

The former is especially important - it sets the expected overall 
direction.  In particular:

	Tnn;....;Architecture=...
		transfer the architecture including byte order
	<regnr>!<value>
		transfer network ordered registers

Andrew

(1) If someone targets GDB at a word only addressable ISA then this will 
need to be clarified.
(2) I'm ignoring XOR endian issues as found on MIPS and PPC.  The bytes 
are ordered according to how the program sees them vis: ``char *memory = 
NULL; memory[i++];''.  XOR endian does wierd stuff.