gdbserver, remote serial protocol and endian issues

gdbserver, remote serial protocol and endian issues

[Paul Bartlett]

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.

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 noticed a brief flurry of posts on the subject about
a year ago but nothing since.

Does anyone have an opinion on this?

Cheers,

Paul

Re: gdbserver, remote serial protocol and endian issues

[Daniel Jacobowitz]

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

Re: gdbserver, remote serial protocol and endian issues

[Daniel Jacobowitz]

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.

> Our application connects to the H-UDI (JTAG)
> port of the SH4 for high speed (~20 MBits/s) 
> access through the back door into the chip.
> 
> The physical implementation includes a 32 bit 
> shift register. What we notice is that if we 
> change endianness then we have to endswap the 
> 32 bit quantity that appears in the register 
> before transferring it to the target machine 
> reg. - it never actually gets into memory.

That's a property of the board, right?  It expects this shift register
to be in its own endianness... or is something else going on?

> > 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.
> 
> Maybe we re-invented the wheel, some. Our
> implementation runs on a box equipped with
> cpu/flash/ram and ethernet and jtag interfaces.
> It does implement the remote protocol in much
> the same way that rproxy does, but also adds
> facilities like posix i/o through the debug
> port.
> 
> Works well. We've used it for debugging both
> 'bare machine' embedded and rtos based apps. 
> (I also brought up a linux kernel with it).

Nice job, although I'm not sure gdbserver is the best base for it; like
I said, it's generally Unix-based.  However, with the other
organizational cleanup I've been adding to it lately, I think there's a
clean place to integrate this sort of thing now.

I don't suppose you're thinking of contributing it?  The POSIX I/O
stuff especially would be nice to have in gdbserver.

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

Re: gdbserver, remote serial protocol and endian issues

[Paul Bartlett]

>
> 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.
Yes, I can see that though if you pick up,
say, a 32 bit quantity off the stack into
a machine reg, then the endianness issue is 
handled for you by the bus interface unit.

It's only when copying anonymous bytestreams
that you have to explicitly handle endianness.

>
> That's a property of the board, right?  It 
> expects this shift register to be in its own 
> endianness... or is something else going on?
>
No it's a property of the H-UDI port, the debug
port built into the chip itself. We can boot
the target through this without having any
external memory at all (can't do much with it
though ;-))

>
> Nice job, although I'm not sure gdbserver is 
> the best base for it; like I said, it's generally 
> Unix-based.  However, with the other organizational 
> cleanup I've been adding to it lately, I think 
> there's a clean place to integrate this sort of 
> thing now.
>

We (SuperH Inc.) have embraced open-source with
gusto. In a matter of a few weeks we had compiler
with nice gui in place from an almost standing
start. gdbserver seemed to be the closest model
to our older proprietary toolchains and provided
an environment that existing users are reasonably
familiar with.

> I don't suppose you're thinking of contributing it?  
> The POSIX I/O stuff especially would be nice to 
> have in gdbserver.

We're in the process of trying to arrange this. Part
of the problem is that Hitachi, who originally designed
the chips is nervous about releasing too much detail
about the debug port. It's a very powerful way to get
into a system through the back door.

Although they've assigned the core IP to us, there
were a few strings attached.

If we open-source the adaptor code, then this will
implicitly release much of the information that
Hitachi are trying to keep under their hats.

It's frustrating :-(


Best,

Paul

Re: gdbserver, remote serial protocol and endian issues

[Andrew Cagney]

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

Re: gdbserver, remote serial protocol and endian issues

[Andrew Cagney]

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

I assume you mean something like a memory read at &foo only works if 
done as a 16 bit operation by the remote target.

> This one is definitely a shortcoming in the remote protocol.

Proposals for an extension to the protocol that implement this have been 
posted (search for e-mail from jtc).  The memory attribute framework was 
introduced in preparation for this.

enjoy,
Andrew

RE: gdbserver, remote serial protocol and endian issues

[Paul Bartlett]

Hi Andrew

>Proceduraly or technically?

Proceduraly. The post was intended to canvas opinion as to whether the
proposed enhancement has sufficient support to warrant further
investigation.

If it does, then some discussion on the technical merits of the changes
follows.

If there's no real support for it then I'll resort to handling the problems
that I'm experiencing in another way. It'd be nice to do it 'cleanly'
though.

Best,

Paul