Peter Maydell writes: > ILP32 for AArch64 is a zombie target -- it is kinda-sorta > supported in some toolchains but has no support in eg > the Linux syscall ABI. The semihosting ABI does not implement > any kind of ILP32 variant -- you can have A32/T32 (AArch32) > semihosting, where register and field sizes are 32 bit, or > you can have A64 (AArch64) semihosting, where register and > field sizes are 64 bit. Yeah, I did ILP32 support for Picolibc; all of the aarch64 asm support needed fixing as ilp32 doesn't specify that register arguments clear the top 32 bits. Seems pretty obvious that it's little used. For semihosting, as the ABI isn't visible to the hardware/emulator, the only reasonable answer that I could come up with was to treat ILP32 the same as the LP64 and pass 64 bit parameters. As picolibc is designed for bare-metal environments, it's pretty easy to support ilp32 otherwise. > I meant, how does the RISCV semihosting ABI specify what > the field size is? To answer my own question, I just looked at > the spec doc and it says "depends on whether the caller is > 32-bit or 64-bit", which implies that we need to look at the > current state of the CPU in some way. Yes. As qemu currently fixes that value based on compilation parameters, we can use the relevant native types directly and ignore the CPU state. Adding dynamic XLEN support to qemu would involve a bunch of work as the same code can be run in both 64- and 32- bit modes, so you'd have to translate it twice and select which to execute based on the CPU state. > Part of why I asked is that the current RISCV implementation > is just looking at sizeof(target_ulong); but the qemu-system-riscv64 > executable AIUI now supports emulating both "this is a 64 bit > guest CPU" and "this is a 32 bit host CPU", and so looking at > a QEMU-compile-time value like "sizeof(target_ulong)" will > produce the wrong answer for 32-bit CPUs emulated in > the qemu-system-riscv64 binary. My guess is maybe > it should be looking at the result of riscv_cpu_is_32bit() instead. Wow. I read through the code and couldn't find anything that looked like it supported that, sounds like I must have missed something? -- -keith