Symbol deduplication fails (.gnu.linkonce vs. COMDAT)

[sicherha]

The i386-tls-gd unit test fails with a duplicate symbol error on epel8. The core issue here is that non-recent versions of glibc (< 2.32) put their thunks into a .gnu.linkonce section, while mold only seems to handle COMDAT deduplication.

How to reproduce

./build-static.sh
docker run --rm -v "$PWD:$PWD:Z" -w "$PWD" -it fedorapackaging/builder:epel8
# Inside the container:
sudo dnf -y install glibc-static.i686
cd test/elf
./i386-tls-gd.sh

Output

Testing i386-tls-gd ... mold: error: duplicate symbol: /usr/lib/gcc/x86_64-redhat-linux/8/32/crtbeginS.o: /usr/lib/crti.o: __x86.get_pc_thunk.bx
collect2: error: ld returned 1 exit status

Analysis

The __x86.get_pc_thunk.bx symbol is defined in two object files: once in a COMDAT (SHF_GROUP) section, once in a .gnu.linkonce section. Apparently mold fails to deduplicate these two.

$ readelf -SsW /usr/lib/gcc/x86_64-redhat-linux/8/32/crtbeginS.o | grep __x86.get_pc_thunk.bx
readelf: /usr/lib/gcc/x86_64-redhat-linux/8/32/crtbeginS.o: Warning: [11]: Info field (10) should index a relocatable section.
  [15] .text.__x86.get_pc_thunk.bx PROGBITS        00000000 00014c 000004 00 AXG  0   0  1
    31: 00000000     0 FUNC    GLOBAL HIDDEN    15 __x86.get_pc_thunk.bx

$ readelf -SsW /usr/lib/crti.o | grep __x86.get_pc_thunk.bx
  [ 7] .gnu.linkonce.t.__x86.get_pc_thunk.bx PROGBITS        00000000 000070 000004 00  AX  0   0 16
    12: 00000000     4 FUNC    GLOBAL HIDDEN     7 __x86.get_pc_thunk.bx

Relevant links

• glibc 2.32 moving from .gnu.linkonce to COMDAT: https://sourceware.org/bugzilla/show_bug.cgi?id=20543
• Related issue in lld: https://reviews.llvm.org/D57294

[rui314]

Ugh, the patch to lld seems very hacky. But doing the same thing in mold should be trivial. I'll implement that. Thank you for filing the issue!

[sicherha]

Your commit looks plausible - but I'm still getting the same error, unfortunately.

[rui314]

I think the new patch fixes the issue. I tested in the fedorapackaging/builder:epel8 docker environment (thank you for giving me the instruction about how to reproduce the issue btw!)