[clang] [llvm] [Clang][Lexer] Reland "Detect SSE4.2 availability at runtime in fastParseASCIIIdentifier" (PR #175452)

[Fangrui Song via cfe-commits]

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 at 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 at entry=0x7ffff7ffe2f0, scope=<optimized out>, reloc_mode=<optimized out>, consider_profiling=consider_profiling at 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 at entry=0x7fffffffdc50, dl_main=dl_main at 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