This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdbserver, remote serial protocol and endian issues

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

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

Anyway, two references:

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

		transfer the architecture including byte order
		transfer network ordered registers


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]