Explore + Document how to work with Big-Endian (and Bi-Endian) Targets

[daniel5151]

#25 (which added support for 32-bit PowerPC architectures) raised some interesting questions regarding how gdbstub should handle big-endian and bi-endian targets.

Namely, should the Registers::gdb_de/serialize methods be configurable based on the target's current endianness? i.e: plumb through some sort of Target API which queries the endianess of the target, and switches between to/from_be_bytes and to/from_le_bytes appropriated?

Unfortunately, this isn't something I can easily test, since I don't have any bi-endian or big-endian targets to play with...
As such, I'm marking this issue as "help wanted," so that hopefully someone who does have experience with bi-endian systems could clarify the situation.

[jamcleod]

When you say "bi-endian" are you referring to runtime-configurable byteorder (as I would interpret it) or fixed-endian systems which can be either ordering? As I feel like each of those would warrant different solutions.

[daniel5151]

From the wikipedia article on Endianness:

Note that the term "bi-endian" refers primarily to how a processor treats data accesses. Instruction accesses (fetches of instruction words) on a given processor may still assume a fixed endianness, even if data accesses are fully bi-endian, though this is not always the case, such as on Intel's IA-64-based Itanium CPU, which allows both.

This seems to imply that "bi-endian" is an umbrella term which encapsulates both the cases you mentioned?

Just to reiterate though, as someone who don't have any hands-on experience working with bi-endian and big-endian systems, I'm not at all sure what the best approach would be in this case (hence the "help wanted" tag on the issue).