assigned to @MaskRay

Just checked with llvm-readelf, which sees

 5: 0000000000000000     0 NOTYPE  WEAK   DEFAULT   UND __morestack@LLVM_13

So who is right? But even if llvm-readelf is right, this is obviously not what we want. Generally undefined symbols shouldn't get LLVM_13, but I can't find any syntax to exclude them in the version script.

If you say this behavior is intentional, I guess we need to change the LLVM build.

Created https://reviews.llvm.org/D100624

llvm-readelf -V should report in such a case.

Created https://reviews.llvm.org/D100624
Thanks! I can confirm that it fixes the issue for the reproducer. Both readelf's read it as

 5: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __morestack

afterwards.

llvm-readelf -V should report in such a case.
It looks pretty inconspicuous to me, but maybe I'm mixing something up:

$ llvm-readelf -V test.so
Version symbols section '.gnu.version' contains 7 entries:
Addr: 0000000000000330 Offset: 0x000330 Link: 2 (.dynsym)
000: 0 (local) 1 (global) 1 (global) 1 (global)
004: 3 (GLIBC_2.2.5) 2 (LLVM_13) 2 (LLVM_13)

Version definition section '.gnu.version_d' contains 2 entries:
Addr: 0000000000000340 Offset: 0x000340 Link: 8 (.dynstr)
0x0000: Rev: 1 Flags: BASE Index: 1 Cnt: 1 Name: test.so
0x001c: Rev: 1 Flags: none Index: 2 Cnt: 1 Name: LLVM_13

Version needs section '.gnu.version_r' contains 1 entries:
Addr: 0000000000000378 Offset: 0x000378 Link: 8 (.dynstr)
0x0000: Version: 1 File: libc.so.6 Cnt: 1
0x0010: Name: GLIBC_2.2.5 Flags: none Version: 3

llvm-readelf -V should report in such a case.

I have figured out the GNU readelf behavior. It maintains max_vd_ndx for the max version id for a definition while iterating over the dynamic symbol table. When it sees the incorrect __morestack@LLVM_13, max_vd_ndx is 0, so it reports an error. When it sees _Z1fv@@LLVM_13, it will update max_vd_ndx but that is too late.

I don't think the constraint is necessary so llvm-readelf probably should stick with the current behavior.

Fixed by 1c00530 (target: 13.0.0)

It would be nice to pick this up for LLVM 12.0.1.

It would be nice to pick this up for LLVM 12.0.1.

Sounds good!

I have same error libLLVM-12.so: __morestack in the LLVM 12

/usr/bin/ld: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libLLVM-12.so: __morestack: invalid needed version 2
/usr/bin/ld: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libLLVM-12.so: error adding symbols: bad value error

It interferes build MESA 21.1.0 and RUST.

This patch 1c00530
not helped for me.

I found solution how to fixit - build LLVM with export LLVM_IAS=1
My LLVM build script: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=llvm12-git

This patch
https://github.com/llvm/llvm-project/commit/
1c00530
not helped for me.
Then it's probably a different bug, because the reproducer in comment 0 was fixed by that commit.

I found solution how to fixit - build LLVM with export LLVM_IAS=1
Interesting that symbol versions are affected by the choice of assembler, especially since the build script doesn't seem to enable LTO. Can you observe a (relevant) difference in the object file for llvm/lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp between LLVM_IAS=1 and without it?

The linker using an assembler would surprise me a bit, but I don't know a lot about this.

I

This patch
https://github.com/llvm/llvm-project/commit/
1c00530
not helped for me.
Then it's probably a different bug, because the reproducer in comment 0 was
fixed by that commit.

Can someone open a new bug for this?

Merged: 6912082

Interesting that symbol versions are affected by the choice of assembler,
especially since the build script doesn't seem to enable LTO. Can you
observe a (relevant) difference in the object file for
llvm/lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp between
LLVM_IAS=1 and without it?

I accidentally found a solution to the problem. Initially, I always bild LLVM with LLVM_IAS=1, but when I removed this line I got this errors in MESA. Only removal -DLLVM_USE_LINKER=lld helped. Then I decided to return LLVM_IAS=1
and then the problem was solved. During the couple of hours that I rebuilt LLVM, there were no new commits. I try reproduce and send objdumps.

Today I double-checked, the error did not repeat itself. The files are identical. It’s strange. Yesterday, I applied a patch and cleaned up the build folder every time, and the patch didn't help. Today this patch is already in the llvm 12 branch. The mistake did not repeat itself today.