Created attachment 131378 [details] Dockerfile showing isolated repro case SUMMARY When I attempt to use valgrind linked with LLD on a binary that was linked with LLD (the LLVM linker), I get the following error: valgrind: mmap(0x........, 4096) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. I am able to consistently reproduce this using just valgrind regression tests (I've picked the badfree test just to have a minimalistic example, but a number of test fails). STEPS TO REPRODUCE 1. Set up lld to be the default system linker 2. Compile valgrind 3.16.1 from source (make check) 3. Run perl tests/vg_regtest ./memcheck/tests/badfree OBSERVED RESULT Test fails. ./memcheck/tests/badfree.stderr.out contains the following error: valgrind: mmap(0x........, 4096) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. This also happens on my custom binary. EXPECTED RESULT Test passes. On a custom binary, I expect valgrind to run normally. SOFTWARE/OS VERSIONS Linux: Ubuntu 16.04 (running in Docker) ADDITIONAL INFORMATION Attaching a Dockerfile that I used to reproduce the issue. I am not sure if this is a LLD bug or a Valgrind bug, I am not sure what steps I'd need to do to find out. Given that it doesn't show up in LLD 9 I'd expect it could be a LLD bug. But on the other hand given the number of open bugs related to mmap failed in UME with error 22 it might as well be a problem on Valgrind side. If this is a clang bug, then it would be useful to be able to extract a minimalistic example that doesn't involve the entire valgrind, which I am not sure how I'd approach. Using that Dockerfile, I run the following commands (using docker 19.03.12 on a x86_64 Ubuntu 16.04 host): # Successful case - LLD 9 $ docker build --build-arg LLVM_MAJOR=9 [...] badfree: valgrind -q ./badfree == 1 test, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == # Failure case - LLD 10 $ docker build --build-arg LLVM_MAJOR=10 [...] badfree: valgrind -q ./badfree *** badfree failed (stderr) *** == 1 test, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == ./memcheck/tests/badfree (stderr) valgrind: mmap(0x........, 4096) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. # Failure case - LLD 11 $ docker build --build-arg LLVM_MAJOR=11 [...] *** badfree failed (stderr) *** == 1 test, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == ./memcheck/tests/badfree (stderr) valgrind: mmap(0x........, 4096) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments.
This seems to be a LLVM bug that has been fixed since. I've compiled lld from the latest source (with ld --version showing: LLD 12.0.0 (https://github.com/llvm/llvm-project.git e2dd86bbfcb4c1888d5e0ff6256a51c906e621cb)) and I did not see the issue anymore. I had to use `./configure LDFLAGS='-Wl,-z,notext'` when compiling Valgrind with LLD 12 otherwise the compilation failed. Using these linker flags with previous releases seems to make no difference. This will unfortunately keep affecting users relying on LLVM linker until LLD 12 is released as stable.
I've tried this with the latest stable LLVM clang+lld (12.0). The reproducer needs a slight modification to work, but valgrind is still broken when using LLD. Make regtest results in the following output: -- Finished tests in exp-bbv/tests/amd64-linux ------------------------- == 698 tests, 157 stderr failures, 19 stdout failures, 0 stderrB failures, 0 stdoutB failures, 3 post failures == As can be seen from for example ./memcheck/tests/vbit-test/vbit-test.stderr.out, the UME 22 error is still there: valgrind: mmap(0x........, 5009408) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. It seems that valgrind is incompatible with LLVM 12, is that expected? Is this likely to be a LLVM bug, or a Valgrind bug?
I doubt it has anything to do with llvm, it's do do with lld, which is much more obscure as I suspect most users of llvm based compilers probably still link with binutils. Almost certainly this is the same as BZ#439046 which has much better diagnostic information so I'm going to close this as a duplicate. *** This bug has been marked as a duplicate of bug 439046 ***