user-level: 0.910
mistranslation: 0.671
files: 0.646
graphic: 0.569
semantic: 0.512
ppc: 0.508
device: 0.505
performance: 0.495
TCG: 0.404
kernel: 0.313
architecture: 0.293
network: 0.288
x86: 0.260
boot: 0.247
i386: 0.232
vnc: 0.215
PID: 0.203
socket: 0.195
register: 0.177
debug: 0.169
risc-v: 0.152
permissions: 0.133
arm: 0.115
peripherals: 0.100
VMM: 0.093
assembly: 0.078
KVM: 0.071
virtual: 0.027
hypervisor: 0.019
--------------------
user-level: 0.993
files: 0.650
x86: 0.170
TCG: 0.070
register: 0.067
debug: 0.059
assembly: 0.041
virtual: 0.023
i386: 0.016
PID: 0.015
kernel: 0.007
performance: 0.006
semantic: 0.005
arm: 0.003
hypervisor: 0.002
network: 0.002
device: 0.002
VMM: 0.002
boot: 0.002
architecture: 0.001
ppc: 0.001
graphic: 0.001
KVM: 0.001
permissions: 0.001
vnc: 0.001
socket: 0.001
peripherals: 0.001
mistranslation: 0.000
risc-v: 0.000

linux-user elf loader issue

all versions up to 4.0 (I didn't test others)
file affected linux-user/elfload.c
function load_elf_image

if (phdr[i].p_type == PT_LOAD) {
           
-            abi_ulong a = phdr[i].p_vaddr - phdr[i].p_offset; 
+            abi_ulong a = phdr[i].p_vaddr ; // - phdr[i].p_offset; 
            if (a < loaddr) {
                loaddr = a;

To the best of my understanding of the elf format p_offset is not a virtual offset. In fact, when I load statically compiled applications, the load fails because the libc before main is trying to access phdr in the executable image but that memory is not mapped -- this is caused by the wrong loaddr above.

Have you got a test case? The check-tcg tests all pass and they are statically linked elfs.

[Expired for QEMU because there has been no activity for 60 days.]