libLLVM and libjulia-codegen seem to use different TypeID's

[vchuravy]

@pchintalapudi just now showed me a bug where we hit the assertion in https://github.com/llvm/llvm-project/blob/f28c006a5895fc0e329fe15fead81e37457cb1d1/llvm/lib/Passes/StandardInstrumentations.cpp#L366

On inspection we see a TypeID corresponding with Module and the allocation point of that typeid is in libjulia-codegen.

nm ~/builds/julia/usr/lib/libjulia-codegen.so | grep _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE
0000000000178243 r _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE

nm ~/builds/julia/usr/lib/libLLVM.so | grep _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE
0000000003303581 V _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE

Tracing the disassembly we saw a load from a global variable and that the ID for disagreed. Now of note is that on my system build of libLLVM:

nm -D /usr/lib/libLLVM-15.so | grep _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE
0000000004a0b796 u _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE@@LLVM_15

u stands for gnu unique. Now we build our version of libLLVM with -fno-gnu-unique to avoid issues around multiple different copies of libLLVM being loaded.
https://bugs.llvm.org/show_bug.cgi?id=48221

-fno-gnu-unique

    On systems with recent GNU assembler and C library, the C++ compiler uses the STB_GNU_UNIQUE binding to make sure that definitions of template static data members and static local variables in inline functions are unique even in the presence of RTLD_LOCAL; this is necessary to avoid problems with a library used by two different RTLD_LOCAL plugins depending on a definition in one of them and therefore disagreeing with the other one about the binding of the symbol. But this causes dlclose to be ignored for affected DSOs; if your program relies on reinitialization of a DSO via dlclose and dlopen, you can use -fno-gnu-unique. 

So we seem to have an issue that libjulia-codegen and libLLVM resolve the same weak symbol to different things...

x-ref: llvm/llvm-project#47565

[vtjnash]

Why is it getting u? That seems a build system issue (https://bugs.llvm.org/show_bug.cgi?id=48221), since that default behavior seems to be a broken part of gnu ld's design. I have hit that same bug with TypeId just trying to run the clang tests.

[vchuravy]

The issue here is not that it's getting u. We have turned gnu-uniqueoff for our builds.

The issue is that seemingly llvm::any_isa is broken for our builds of LLVM 14 (and potentially above).
Prem hit this when running with JULIA_LLVM_ARGS="--print-before-all" on NewPM.

[vchuravy]

vchuravy@odin ~/b/julia> readelf -W --syms usr/lib/libLLVM.so | grep _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE
 31761: 0000000003303581     1 OBJECT  WEAK   DEFAULT   14 _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE@@JL_LLVM_14.0
102453: 0000000003303581     1 OBJECT  WEAK   DEFAULT   14 _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE

vchuravy@odin ~/b/julia> readelf -W --syms usr/lib/libjulia-codegen.so | grep _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE
  2478: 0000000000178243     1 OBJECT  LOCAL  DEFAULT   15 _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE
  
vchuravy@odin ~/b/julia> readelf -W --syms /usr/lib/libLLVM.so | grep _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE
 17655: 0000000004a0b796     1 OBJECT  UNIQUE DEFAULT   13 _ZN4llvm3Any6TypeIdIPKNS_6ModuleEE2IdE@@LLVM_15

rui314/mold#145 (comment)

[vtjnash]

Ah, so the question is how we accidentally forced it to be local instead of weak when linking our libjulia-codegen. Maybe a fault of our expmap file?