On 10/4/24 09:30, Philippe Mathieu-Daudé wrote:
Philippe Mathieu-Daudé (25):
gdbstub/helpers: Have ldtul_p() definition use ldn_p()
target/hexagon: Replace ldtul_p() -> ldl_p()
target/alpha: Replace ldtul_p() -> ldq_p()
target/s390x: Replace ldtul_p() -> ldq_p()
gdbstub/helpers: Introduce ldtul_$endian_p() helpers
target/alpha: Use explicit little-endian LD/ST API
target/hexagon: Use explicit little-endian LD/ST API
hw/i386: Use explicit little-endian LD/ST API
target/i386: Use explicit little-endian LD/ST API
target/avr: Use explicit little-endian LD/ST API
linux-user/i386: Use explicit little-endian LD/ST API
target/loongarch: Use explicit little-endian LD/ST API
target/sh4: Use explicit little-endian LD/ST API
target/tricore: Use explicit little-endian LD/ST API
target/rx: Use explicit little-endian LD/ST API
target/riscv: Use explicit little-endian LD/ST API
hw/m68k: Use explicit big-endian LD/ST API
target/m68k: Use explicit big-endian LD/ST API
hw/sparc: Use explicit big-endian LD/ST API
target/sparc: Use explicit big-endian LD/ST API
target/hppa: Use explicit big-endian LD/ST API
hw/s390x: Use explicit big-endian LD/ST API
target/s390x: Use explicit big-endian LD/ST API
target/openrisc: Use explicit big-endian LD/ST API
hw/ppc/e500: Use explicit big-endian LD/ST API
The sh4, rx, and riscv targets *can* support multiple endianness.
While we removed sh4eb for system mode, we still support sh4eb-linux-user, and therefore
the target/sh4 patch affecting gdbstub is wrong.
RX sets endianness via a pin sampled at reset; if we ever implement this, it would be via
a property on the cpu. RISCV sets endianness via a couple of bits in MSTATUS; system mode
would always use little-endian, but riscv64eb-user isn't out of the question.
While we have never supported rx or riscv in big-endian, but there's no reason that we
can't, and those target/ patches make things harder. Since target/ will *always* have
TARGET_BIG_ENDIAN available, I don't see that we're saving anything there.
r~
