On Fri, 24 Nov 2023 21:43:54 +0000 Tj <deb...@iam.tj> wrote:
$ qemu-aarch64-static -strace sid-aarch64/usr/lib/ld-linux-aarch64.so.1 --verify sid-aarch64/usr/bin/aarch64-linux-gnu-g++-13 482357 brk(NULL) = 0x0000005500042000 482357 openat(AT_FDCWD,"sid-aarch64/usr/bin/aarch64-linux-gnu-g++-13",O_RDONLY|O_CLOEXEC) = 3 482357 read(3,0x2841280,832) = 832 482357 getcwd(0x5500041980,128) = 18 482357 mmap(0x0000000000400000,937984,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0)Segmentation fault (core dumped)
The crash is because the guest g++ executable overlaps the host qemu executable, and this mmap clobbers qemu itself. There is some code in qemu that *attempts* to avoid this situation, but it *only* works when the main executable is the one with the conflict.
In this case, you're running the g++ executable indirectly, with ld-linux-aarch64.so.1 as the main executable, so qemu cannot see the conflict.
Solving this is only possible with complete separation of host and guest address spaces. QEMU does this by default when running 32-bit guest on 64-bit host, but we have no general-purpose solution for 64-bit guest.
You can avoid some of the problems with QEMU_RESERVED_VA=0x1000000000, giving the guest a dedicated 40-bit address space, but that will cause other failures with applications that expect more virtual address space.
It is a long-term goal for QEMU to be able to provide a complete separate virtual address space, but that will not happen soon.
