Hi Laurent,
On 27/7/26 18:51, Richard Henderson wrote:
On 7/27/26 04:48, Laurent Vivier wrote:
On real SH4 hardware, the address space is split between user mode
(U0, 0x00000000-0x7fffffff) and kernel mode (P1-P4,
0x80000000-0xffffffff),
so TARGET_VIRT_ADDR_SPACE_BITS was set to 31 for CONFIG_USER_ONLY.
However, qemu-user does not emulate the MMU, so this limit is not needed.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [*]
The only effect is to restrict reserved_va to 2 GB, causing OOM failures
for memory-intensive builds (e.g. webkit2gtk on Debian sh4 buildds).
Set TARGET_VIRT_ADDR_SPACE_BITS to 32 unconditionally, like most other
32-bit targets. Also fix the TASK_UNMAPPED_BASE macro to use 1ull instead
of 1u to avoid undefined behavior when shifting by 32.
Reported-by: John Paul Adrian Glaubitz <[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>
---
linux-user/sh4/target_mman.h | 2 +-
target/sh4/cpu-param.h | 6 +-----
2 files changed, 2 insertions(+), 6 deletions(-)
So, the goal is to run things under qemu-linux-user that can't run on
hardware?
I'm not necessarily opposed, though there have been software systems
that know that the upper bit is unused and reuse it for tagged
pointers. Emacs did so, sometime last century. I'm sure there were
others. Anyway that's the reason we currently limit qemu-linux-user
like the hardware does.
If you're going to drop that, you might do this for all targets:
mips/cpu-param.h:# define TARGET_VIRT_ADDR_SPACE_BITS 31
sh4/cpu-param.h:# define TARGET_VIRT_ADDR_SPACE_BITS 31
If so please add a comment ([*]) around these definitions.
