clang 21.1.0-rc1 creates broken executables on Cygwin/MinGW when linked with GNU ld.bfd

[jeremyd2019]

with llvm/clang 20.1.8 (with Cygwin-related patches backported) I am able to build llvm, clang, and lld with clang and am able to strip the resulting executables.

with llvm/clang 21.1.0-rc1 I am able to build with clang but when I attempt to strip executables with llvm-strip I get an error unexpected associative section index (#53433) and when I attempt to strip executables with binutils 2.44 strip I get an executable that crashes on startup (I was able to catch it once during pseudo-relocations).

I don't have much detail yet, but I wanted to get this recorded and have a place to track the investigation. I imagine my next step would be to set up a git bisect operation to try to figure out what's going on. I don't have any ideas on how to reduce a test case, just that lld.exe and clang.exe are bugged, but simple C and C++ hello world executables are not.

/cc @mstorsjo @tyan0 @kikairoya

[jeremyd2019]

examples of broken executables lld.zip clang-21.zip

[kikairoya]

The direct cause of unexpected associative section index by llvm-strip is this symbol table entry:

[870](sec  3)(fl 0x00)(ty    0)(scl   3) (nx 1) 0x0000000000000788 .rdata
AUX scnlen 0x15c nreloc 87 nlnno 0 checksum 0x6a2beba4 assoc 29 comdat 5

This entry is "Auxiliary Format 5: Section Definitions", as scl (storage class)=3. This symbol defines a linked COMDAT section referred by 29th entry of section table but no such entry in the section table.

This entry is shown at just before above:

[869](sec  1)(fl 0x00)(ty   20)(scl   2) (nx 0) 0x0000000000010410 _ZN4llvm4yaml11needsQuotesENS_9StringRefEb

and disassembly of this function indeed refers that .rdata address:

   1004115c6:   4c 8d 05 bb 71 00 00    lea    0x71bb(%rip),%r8        # 100418788 <.rdata>

I guess this contains jump table of switch block here.

llvm-project/llvm/include/llvm/Support/YAMLTraits.h

Line 707 in e1ac57c

switch (C) {

It may implies unnamed data can't be relocated correctly.

I'll dig further, including binutils' problem.

[kikairoya]

This repro can cause cannot execute binary file: Exec format error after llvm-strip-ed.

The switch block needs a size to be transformed to table jump and a number of other COMDAT sections before emit it to increment index.
Although, binutils' strip doesn't break this.

// RUN: clang %s -g -O -c -DOBJ1 -o %t.1.o
// RUN: clang %s -g -O -c -DOBJ2 -o %t.2.o
// RUN: clang %s -g -O -c -DEXE -o %t.e.o
// RUN: clang %t.e.o %t.1.o %t.2.o -g -o %t.exe
// RUN: llvm-strip %t.exe
// RUN: %t.exe 1


int test1(int, int);
int test2(int);
int test3(int);

template <typename T>
int test1(int code, int data) {
  switch (code) {
  case 1: return 3;
  case 3: case 5: return code + 2;
  case 7: return test3(code);
  case 8: case 9: return test3(code+1);
  case 12: case 13: case 14: case 17: return data;
  case 32: case 33: case 34: case 37: return test3(code/2);
  default: return 0;
  }
}

#ifdef OBJ1

template int test1<char>(int, int);
template int test1<short>(int, int);
template int test1<unsigned>(int, int);
template int test1<long>(int, int);
template int test1<float>(int, int);
template int test1<double>(int, int);
template int test1<void>(int, int);

int test2(int code) {
    return test1<int>(code, 3);
}

#endif

#ifdef OBJ2

int test3(int code) {
    return code * 2;
}

#endif

#ifdef EXE

int main(int argc, char **argv) {
    return argv[0] ? test2(argc) : test3(argc);
}

#endif

[kikairoya]

I couldn't reproduce 21.1.0-rc1 breakage with binutils. May optimizations or patches be sensitive?
Anyway, it seems odd that BFD ld doesn't drop COMDATs when emit final EXE. LLD drops them, that compiles with PE spec.
To workaround, -Wl,-x removes COMDAT entries but keep debug info, then llvm-strip works fine.

[kikairoya]

It may implies unnamed data can't be relocated correctly.

Naming each jump table uniquely still causes cannot execute binary file: Exec format error.

// RUN: clang %s -g -O -S -DOBJ1 -o %t.1.s
// RUN: sed -i '/.rdata,"dr",associative/s/.rdata\(.*,\)\(_Z[^,]*\)/.rdata$\2\1\2/' %t.1.s
// RUN: clang %t.1.s -g -O -c -DOBJ1 -o %t.1.o

[kikairoya]

https://sourceware.org/cgit/binutils-gdb/tree/bfd/coffcode.h#n986 (link to GPLv3 code)
"gnu" means GCC? Seems like it would be difficult to fix "right"...

Their commit 6aadf8a04d162feb2afe3c41f5b36534d661d447 says "optimize handle_COMDAT".
Can you try older binutils before Jun-18-2023 ?

[jeremyd2019]

Looking at Cygwin packages, currently only 2.42, 2.43.1, and 2.44 are available .

I don't have time this weekend to look at this, but I (or someone) should:

• Test to make sure this isn't similarly broken on MinGW (I thought I did, but then remembered that llvm-mingw uses lld not binutils 🤦) That'd make this bug more important to more people.
• try to bisect this - it didn't do this in 20.1.8, so clearly something has changed on this end of things, not in binutils

[kikairoya]

I got a segmentation fault in do_pseudo_reloc while loading cygLLVM-21-rc1.dll, during bootstrap with llvm.cygport and clang.cygport. It took me half a day to build...

[kikairoya]

$ objcopy -g cygLLVM-21-rc1.dll.orig /usr/bin/cygLLVM-21-rc1.dll breaks $ /usr/bin/clang --version but $ objcopy -X ... does not.

[kikairoya]

I have got SIGTRAP in do_pseudo_reloc from llvm-tblgen stripped by binutils.
-DLLVM_ENABLE_EH=ON -DLLVM_ENABLE_RTTI=ON are required.
I can bisect from now.

[kikairoya]

branch point of release/20.x seems already bad for llvm-tblgen.