Re: linux-user cannot allocate stack memory on riscv64 host due to non-zero guest_base

[Richard Henderson]

On 6/25/24 04:37, Andreas Schwab wrote:
> When running qemu-riscv64 on a riscv64 host executing a ET_EXEC riscv64
> binary it cannot allocate memory for the stack:
>
> $ qemu-riscv64 -d page ./hello.riscv64
> host mmap_min_addr=0x10000
> Locating guest address space @ 0x3ee000
> page layout changed following mmap
> start            end              size             prot
> 0000000000010000-0000000000013000 0000000000003000 ---
> page layout changed following mmap
> start            end              size             prot
> 0000000000010000-0000000000011000 0000000000001000 r-x
> 0000000000011000-0000000000013000 0000000000002000 ---
> page layout changed following mmap
> start            end              size             prot
> 0000000000010000-0000000000011000 0000000000001000 r-x
> 0000000000011000-0000000000013000 0000000000002000 rw-
> mmap stack: Cannot allocate memory
>
> The issue is that guest_base is non-zero, which turns the target_mmap
> call with zero base in setup_arg_pages into a host mmap call with
> non-zero base.  On other hosts like x86_64 or aarch64, guest_base
> remains zero and the issue does not occur.

You need to be more precise in your bug reports, because it works for me.
Everything non-PIE, statically linked:

./qemu-riscv64: ELF 64-bit LSB executable, UCB RISC-V, RVC, double-float ABI, version 1 
(SYSV), statically linked, BuildID[sha1]=92e2b4b9a2cbcc91ac029a49ec72eaefe5111f38, for 
GNU/Linux 4.15.0, with debug_info, not stripped

/home/rth/a.out: ELF 64-bit LSB executable, UCB RISC-V, RVC, double-float ABI, version 1 
(SYSV), statically linked, BuildID[sha1]=4c52c576a0452e97d9117b89dd317c88460b0768, for 
GNU/Linux 4.15.0, not stripped

$ ./qemu-riscv64 -d page ~/a.out
host mmap_min_addr=0x1000
Locating guest address space @ 0x3ff000
page layout changed following mmap
start            end              size             prot
0000000000010000-0000000000084000 0000000000074000 ---
...
end_code    0x0000000000078388
start_code  0x0000000000010000
start_data  0x00000000000795b0
end_data    0x000000000007e8a8
start_stack 0x0000003f812224a0
brk         0x0000000000084000
entry       0x000000000001041c
argv_start  0x0000003f812224a8
env_start   0x0000003f812224b8
auxv_start  0x0000003f81222570
...
Hello, World!


I don't doubt that you see a problem, but I need a reproducer, not a guess as to what the 
problem might be.  Certainly guest_base is *not* it.  One can always force the use of a 
non-zero base with -B or -R.


r~