Re: gdbserver, remote serial protocol and endian issues

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Apr 08, 2002 at 11:47:59AM +0100, Paul Bartlett wrote:
> Hi Folks,
> 
> We've developed an implementation of gdbserver that
> runs in a box interfacing the debug ports of SuperH
> SH4/SH5 targets to ethernet.
> 
> When connecting to a target cpu, various memory mapped
> registers must be initialised in order to configure 
> the external bus interfaces, clock generators and 
> so forth.
> 
> This achieved by doing pokes from script files.
> 
> The target may be jumper configured to be either big 
> or little endian.
> 
> Unfortunately, the remote serial protocol makes no
> distinction between writes to memory and writes to
> memory mapped registers - you just get a byte stream
> in target endian order.
> 
> In our case, the registers are not byte addressable
> and need to be written variously as 8, 16 and 32 bit
> quantities. Again, remote serial protocol does not
> provide for access size definition.

This one is definitely a shortcoming in the remote protocol.  The lack
of endianness information may be, also... that's open for discussion.

> In order to get things to work at all, we've had to
> embed knowledge of specific CPU variants in the
> gdbserver code together with an indication of the
> target endianness - messy to say the least, and a
> pain to maintain.
> 
> On an aesthetic note, when reading and writing CPU
> registers, the transfer really ought to be endian
> neutral - i.e. in a consistent format that does
> not change with the endianness of the target. Network
> byte order perhaps? This would also remove the need
> for gdbserver to be aware of target endianness.

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.

> 
> I noticed a brief flurry of posts on the subject about
> a year ago but nothing since.
> 
> Does anyone have an opinion on this?

My first impression is that gdbserver is the wrong tool for the job. 
Gdbserver is meant as a remote stub for Unix-like systems.  You're not
running it on a Unix-like system; you're using it as a proxy, right? 
Since GDB already has a stub to speak to the hardware monitor on SH4
boards, as far as I'm aware.  This sounds like a job for rproxy
(http://world.std.com/~qqi) instead.

You definitely did highlight some failures of the remote protocol,
though.  After I finish my current project I intend to update the
documentation of the protocol and see what needs fixing.

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