Description
openedon Mar 23, 2023
@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