| Message ID | 20241004163042.85922-1-philmd@linaro.org |
|---|---|
| Headers | show |
| Series | misc: Use explicit endian LD/ST API | expand |
On 4/10/24 18:30, Philippe Mathieu-Daudé wrote: > For targets (or HW) which are only built for a particular > endianness, the generic LD/ST helpers are defined as the > target endianness variant. For example, on big-endian > targets, stl_p() is equivalent of stl_be_p(). > > This series replaces in bulk these LD/ST calls. This is the first part where we only convert the targets built for a single endianness. The rest (MIPS, ARM, PPC, MicroBlaze and Xtensa) will be handled in different series. I'm keeping hw/virtio/virtio-config-io.c last. Possibly current API will then be restricted to user-emu & system/ to avoid further uses. $ git grep -wlE '(ld|st)t?u?[wlq]_p' hw/mips/bootloader.c hw/mips/fuloong2e.c hw/mips/malta.c hw/ppc/spapr.c hw/ppc/spapr_vhyp_mmu.c target/arm/cpu.c target/arm/gdbstub.c target/arm/gdbstub64.c target/microblaze/gdbstub.c target/mips/gdbstub.c target/ppc/gdbstub.c target/ppc/mmu-hash64.h target/xtensa/gdbstub.c accel/tcg/user-exec.c hw/virtio/virtio-config-io.c include/exec/cpu-all.h include/gdbstub/helpers.h monitor/hmp-cmds-target.c system/ioport.c system/memory_ldst.c.inc > This is helpful for the single binary project where we > want to build a single binary for multiple targets of > different endianness. > > 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 > > hw/m68k/bootinfo.h | 28 ++--- > include/gdbstub/helpers.h | 6 +- > hw/i386/multiboot.c | 36 +++--- > hw/i386/x86-common.c | 26 ++--- > hw/m68k/mcf5208.c | 2 +- > hw/m68k/next-cube.c | 2 +- > hw/m68k/q800.c | 4 +- > hw/ppc/ppce500_spin.c | 24 ++-- > hw/s390x/ipl.c | 4 +- > hw/s390x/s390-pci-inst.c | 166 +++++++++++++-------------- > hw/sparc/leon3.c | 42 +++---- > hw/sparc/sun4m.c | 6 +- > hw/sparc64/sun4u.c | 6 +- > linux-user/i386/signal.c | 4 +- > target/alpha/gdbstub.c | 2 +- > target/avr/gdbstub.c | 4 +- > target/hexagon/gdbstub.c | 10 +- > target/hppa/gdbstub.c | 2 +- > target/i386/gdbstub.c | 30 ++--- > target/i386/tcg/sysemu/excp_helper.c | 4 +- > target/i386/xsave_helper.c | 32 +++--- > target/loongarch/gdbstub.c | 8 +- > target/m68k/gdbstub.c | 2 +- > target/m68k/helper.c | 10 +- > target/openrisc/gdbstub.c | 2 +- > target/riscv/gdbstub.c | 14 +-- > target/rx/cpu.c | 2 +- > target/rx/gdbstub.c | 24 ++-- > target/s390x/gdbstub.c | 34 +++--- > target/s390x/ioinst.c | 2 +- > target/sh4/gdbstub.c | 36 +++--- > target/sparc/gdbstub.c | 6 +- > target/tricore/gdbstub.c | 2 +- > 33 files changed, 292 insertions(+), 290 deletions(-) >
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~
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
On 10/7/24 00:52, Pierre Muller wrote: >> 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? Yes, I'd forgotten about that. Indeed, Sparc v9 has a couple of PSTATE bits that set the endianness, exactly like Arm and Power, which qemu has not implemented for system mode. r~