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]

gdbserver, remote serial protocol and endian issues

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?



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