Package: qemu-user-static Version: 1:7.2+dfsg-7+deb12u2 Followup-For: Bug #1053101
Debugging across an architecture boundary when the architecture is emulated is... painful! However, as I dig in from both sides this is pointing to an issue with PIE handling. E.g.: $ 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) $ qemu-aarch64-static -strace sid-aarch64/usr/lib/ld-linux-aarch64.so.1 --verify sid-aarch64/usr/bin/ls 493812 brk(NULL) = 0x0000005500042000 493812 openat(AT_FDCWD,"sid-aarch64/usr/bin/ls",O_RDONLY|O_CLOEXEC) = 3 493812 read(3,0x28412a0,832) = 832 493812 getcwd(0x5500041970,128) = 18 493812 mmap(NULL,334096,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005502844000 493812 mmap(0x0000005502850000,268560,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x0000005502850000 493812 munmap(0x0000005502844000,49152) = 0 493812 munmap(0x0000005502892000,14608) = 0 493812 mprotect(0x0000005502873000,114688,PROT_NONE) = 0 493812 mmap(0x000000550288f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2f000) = 0x000000550288f000 493812 mmap(0x0000005502891000,2320,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x0000005502891000 493812 close(3) = 0 493812 exit_group(0) Take a close look at the address of the mmap()s: 0x0000000000400000 vs 0x0000005502850000 - this hints at the difference handling of PIE and non-PIE. The latter (for the PIE executable `ls`) does an initial `mmap(NULL, length_of_binary+64k), ...` This looks like it may be a sign of PIE and Address Space Layout Randomisation getting confused in the QEMU code between the qemu binary itself and the target it is interpretting for. For a GCC binary that is PIE it works: file /usr/bin/aarch64-linux-gnu-ld.gold /usr/bin/aarch64-linux-gnu-ld.gold: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=21bf827bc36e1b6cd7d8b280d5b5d385b4946d17, for GNU/Linux 3.7.0, stripped $ qemu-aarch64-static -strace sid-aarch64/usr/lib/ld-linux-aarch64.so.1 --verify sid-aarch64/usr/bin/aarch64-linux-gnu-ld.gold 505564 brk(NULL) = 0x0000005500042000 505564 openat(AT_FDCWD,"sid-aarch64/usr/bin/aarch64-linux-gnu-ld.gold",O_RDONLY|O_CLOEXEC) = 3 505564 read(3,0x2841280,832) = 832 505564 getcwd(0x5500041980,128) = 18 505564 mmap(NULL,5765104,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005502844000 505564 mmap(0x0000005502850000,5699568,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x0000005502850000 505564 munmap(0x0000005502844000,49152) = 0 505564 munmap(0x0000005502dc0000,14320) = 0 505564 mprotect(0x0000005502d72000,73728,PROT_NONE) = 0 505564 mmap(0x0000005502d84000,184320,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x524000) = 0x0000005502d84000 505564 mmap(0x0000005502db1000,59376,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x0000005502db1000 505564 close(3) = 0 505564 exit_group(0) In the qemu code in `./accel/tcg/translate-all.c::page_find_alloc()` there are calls to the built-in glib-2.0 g_new0() on the host. Maybe PIE affects how the glib functions form the underlying mmap() call?
