Le 05/10/2024 à 03:39, Richard Henderson a écrit :
> 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.
Isn't this also true for the sparc CPU?
At least llvm seems to think so:
$ ssh gcc421 /usr/bin/llvm-mc-18 --version
Debian LLVM version 18.1.8
Optimized build.
Registered Targets:
aarch64 - AArch64 (little endian)
....
sparc - Sparc
sparcel - Sparc LE
sparcv9 - Sparc V9
systemz - SystemZ
Pierre Muller