MaskRay wrote: > > it seems like the tsan instrumented binaries just segfault after one of > > these changes. cmake config used by the buildbot is: > > ``` > > cmake -DCMAKE_C_COMPILER_LAUNCHER=ccache > > -DCMAKE_CXX_COMPILER_LAUNCHER=ccache -DLLVM_USE_SANITIZER=Thread > > -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON > > -DLLVM_OPTIMIZED_TABLEGEN=ON > > '-DLLVM_ENABLE_PROJECTS=llvm;clang-tools-extra;clang' '-DLLVM_LIT_ARGS=-v > > -vv' -GNinja ../llvm-project/llvm > > ``` > > > > > > > > > > > > > > > > > > > > > > > > relevant test target is `check-clangd`. > > I'm able to reproduce, and executing the clang binary seg faults immediately. > Here's the stack trace: > > ```c++ > #0 0x000055555655c103 in __tsan_func_entry () > #1 0x000055555f208c5b in fastParseASCIIIdentifier(char const*, char const*) > [clone .resolver] () > #2 0x00007ffff7fceb82 in elf_machine_lazy_rel (map=0x7ffff7ffe2f0, > scope=<optimized out>, l_addr=<optimized out>, reloc=0x5555563e9280, > skip_ifunc=<optimized out>) > at ../sysdeps/x86_64/dl-machine.h:545 > #3 elf_dynamic_do_Rela (map=0x7ffff7ffe2f0, scope=<optimized out>, > reladdr=<optimized out>, relsize=<optimized out>, nrelative=<optimized out>, > lazy=<optimized out>, > skip_ifunc=<optimized out>) at ./elf/do-rel.h:99 > #4 _dl_relocate_object_no_relro (l=l@entry=0x7ffff7ffe2f0, scope=<optimized > out>, reloc_mode=<optimized out>, consider_profiling=<optimized out>) at > ./elf/dl-reloc.c:296 > #5 0x00007ffff7fd23c1 in _dl_relocate_object (l=l@entry=0x7ffff7ffe2f0, > scope=<optimized out>, reloc_mode=<optimized out>, > consider_profiling=consider_profiling@entry=0) > at ./elf/dl-reloc.c:346 > #6 0x00007ffff7fe4363 in dl_main (phdr=<optimized out>, phnum=<optimized > out>, user_entry=<optimized out>, auxv=<optimized out>) at ./elf/rtld.c:2289 > #7 0x00007ffff7fe0bc6 in _dl_sysdep_start > (start_argptr=start_argptr@entry=0x7fffffffdc50, > dl_main=dl_main@entry=0x7ffff7fe2560 <dl_main>) at > ../sysdeps/unix/sysv/linux/dl-sysdep.c:140 > #8 0x00007ffff7fe22a1 in _dl_start_final (arg=0x7fffffffdc50) at > ./elf/rtld.c:497 > #9 _dl_start (arg=0x7fffffffdc50) at ./elf/rtld.c:582 > #10 0x00007ffff7fe1148 in _start () from /lib64/ld-linux-x86-64.so.2 > ``` > > Here's the disassembly: > > ```c++ > Dump of assembler code for function __tsan_func_entry: > 0x000055555655c0f0 <+0>: endbr64 > 0x000055555655c0f4 <+4>: mov %rdi,%rsi > 0x000055555655c0f7 <+7>: mov $0xfffffffffffff840,%rax > 0x000055555655c0fe <+14>: mov %fs:0x28(%rax),%rdi > => 0x000055555655c103 <+19>: mov 0x18(%rdi),%rax > 0x000055555655c107 <+23>: lea 0x8(%rax),%rcx > 0x000055555655c10b <+27>: test $0xff0,%ecx > 0x000055555655c111 <+33>: je 0x5555565531f0 > <_ZN6__tsan21TraceRestartFuncEntryEPNS_11ThreadStateEm> > ``` > > From here, I don't really know how to proceed. I would love some help if > anybody has a clue. Perhaps this is a TSan issue?
This crash will be fixed by the upcoming glibc 2.44 release. The precise conditions to reproduce on glibc < 2.44 are: 1. -z lazy (with -z now/LD_BIND_NOW the JUMP_SLOTs are done first, and the reloc ranges merge so IRELATIVE is deferred past them); 2. the resolver makes an external PLT call (dynamic __cpu_indicator_init from libgcc_s.so.1 — a static local copy calls directly, no PLT, no crash); 3. R_X86_64_IRELATIVE sits in .rela.dyn, processed before .rela.plt (mold/lld on x86-64; GNU ld on arm32/ppc/ppc64/loongarch — but not GNU ld on x86-64, which parks it in .rela.plt); 4. the resolver's module is loaded at a nonzero bias (PIC: any DSO, or a PIE exe). --- On musl systems, this function multi-versioning use may probably be a deoptimization due to `__cpu_indicator_init` function call in the hot path. https://github.com/llvm/llvm-project/pull/175452 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
