qemu-arm-static 5.1 can't run gcc

Issue discovered while trying to build pikvm (1)

Long story short: when using qemu-arm-static 5.1, gcc exits whith message:

Allocating guest commpage: Operation not permitted


when using qemu-arm-static v5.0, gcc "works"

Steps to reproduce will follow 

(1)  https://github.com/pikvm/pikvm/blob/master/pages/building_os.md

Steps to reproduce

1. Download and extract attached tarball.

$ make # will build the docker container

$ make run # will enter the container

# once in the container, run 

# /qemu-arm-static-50 /bin/bash /runme.sh




Additional info,

error message text ( "Allocating guest commpage" ) found in this commit:


https://fossies.org/diffs/qemu/5.0.0_vs_5.1.0-rc0/linux-user/elfload.c-diff.html

Anyone? Seriously, the problem really exists and we even made a case that reproduces it. Someone please take a look at this.

Plz take a look at this issue please.

This has been fixed in mainline, probably commit
8ef618859c379fdce81c91bc93e0574e36ea76ff.


Released with QEMU v5.2.0.

I'm still seeing this with qemu 5.2.0

armv7a-softfp-linux-gnueabi-gcc -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp   -Wl,-O1 -Wl,--as-needed  glibc-test.c   -o glibc-test
Allocating guest commpage: Operation not permitted



$ qemu-arm --version
qemu-arm version 5.2.0 (Debian 1:5.2+dfsg-6)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers

I’m seeing this error on a totally different file:

I’ve made a short test program (hello world-ish) and compiled it with the OpenWrt toolchain but added -static so I can run it on the host using qemu-user-arm:

$ STAGING_DIR=$PWD/staging_dir PATH=staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-7.5.0_musl_eabi/bin:$PATH arm-openwrt-linux-muslgnueabi-gcc -Os -pipe -g3 -fno-caller-saves -fno-plt -fhonour-copts -mfloat-abi=hard -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -static x.c
$ ./a.out 
Allocating guest commpage: Operation not permitted


Heh, even if I omit -static …

It works with sudo, but that can’t be the fix…

Could you check the result of "sysctl vm.mmap_min_addr"

65536 is the value that works for me.

@aurent-vivier Checked.
This value does not affect the bug, after changing it, I still get an error.

Anyone?

I've been unable to replicate the crash with any of the instructions here. Certainly all the statically compiled unit tests work and I've just done a build of QEMU in an emulated Debian Buster (Armel) docker image.

Okay, what do you think this problem might be related to? I'm glad your tests are working, but I'm definitely not the only one with this problem.

I think the output of "sysctl vm" could help to identify which parameter is involved in the problem. You can also compare the output of "sudo sysctl vm" and "sysctl vm"

In my case, sudo does not affect this bug. My output in attachements.

Sup?

Okay, it was found experimentally that the problem is reproduced if vm.mmap_min_addr is greater than 53249. If from 0 to 53249 - everything works. What can this be related to?

I mean [0...52348] is working.

Sorry, an error in previous message.

Fixed and detailed diagnostics:

[0    ...  53248] - working
[53249 ... 61440] - Cannot allocate memory
[61441 ... 65536 and higher] - Operation not permitted

Can confirm this bug on fresh Linux Arch and Debian Linux installation.
I need just nothing to reproduce it: Just install fresh arch and do steps described in comment #1