mstorsjo
liblldb.dll doesn't build with LLVM12 + LTO | LLD error
Hello Martin !
First of all thanks again for this awesome project. It took me several hours to play with it and edit scripts to finally get what I wanted , extremely helpful. I had some issues but I guess I will create dedicated tickets for each one of them.
So the issue I wanted to report here was when I tried to build LLDB with LTO enabled, the linker failed with an error. I tried both Thin and Full LTO, same error in both cases. However liblldb.dll builds properly when LTO is disabled.
Heart of the error: lld-link: error: undefined symbol: thread-local initialization routine for lldb_private::repro::Recorder::g_global_boundary
I checked the code source and for me everything makes sense. The TLS variable is defined in ReproducerInstrumentation.cpp which is compiled and archived in liblldbUtility.a that is used to generate liblldb.dll but somehow LLD doesn't find it. I checked the cmake and generated ninja file and the archive is referenced as expected.
Any ideas ? I want to say it is a bug in LTO since it works when LTO is disabled but I might be wrong and just looking for a scape goat and maybe I did something wrong.
I use Win10 with msys-mingw64 and I was trying a stage 2 LTO with LLVM 12 + MinGW64 8.0.0 + ucrt + libcxx
It sounds a little bit like https://github.com/mstorsjo/llvm-mingw/issues/61
More details:
$ ninja -j7 install/strip [1/6] Linking CXX shared library bin\liblldb.dll FAILED: bin/liblldb.dll lib/liblldb.dll.a cmd.exe /C "cd . && D:\c12\build\bin\clang++.exe -Wa,-mbig-obj -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -flto=full -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -O3 -DNDEBUG -fuse-ld=lld -flto=full -shared -o bin\liblldb.dll -Wl,--out-implib,lib\liblldb.dll.a -Wl,--major-image-version,12,--minor-image-version,0 @CMakeFiles\liblldb.rsp && cd ." lld-link: error: undefined symbol: thread-local initialization routine for lldb_private::repro::Recorder::g_global_boundary
referenced by D:/c12/scripts/llvm-project/lldb/source/API/SBAddress.cpp tools/lldb/source/API/CMakeFiles/liblldb.dir/SBAddress.cpp.obj referenced by D:/c12/scripts/llvm-project/lldb/source/API/SBAttachInfo.cpp tools/lldb/source/API/CMakeFiles/liblldb.dir/SBAttachInfo.cpp.obj referenced by D:/c12/scripts/llvm-project/lldb/source/API/SBBlock.cpp tools/lldb/source/API/CMakeFiles/liblldb.dir/SBBlock.cpp.obj referenced 65 more times clang-12: error: linker command failed with exit code 1 (use -v to see invocation) [2/6] Building CXX object tools/llvm-config/CMakeFiles/llvm-config.dir/llvm-config.cpp.obj ninja: build stopped: subcommand failed.
Hi,
I think this might be a bug/"missing feature" for mingw/itanium cases of extern TLS objects in combination with LTO. Extern TLS objects, i.e. ones that are accessed across object file boundaries, trigger a number of less than trivial constructs - if I don't misremember, the construct does involve weak symbols too.
I remember trying out weak symbols in combination with LTO (I've got a fairly small and neat "unit test" for that feature), and I remember that they fail. So I think it might boil down to that same issue.
I've only tested using the 2stage/LTO build for building a toolchain that runs on linux - thanks for testing! Now I know that this is something I need to look into closer at some point.
FWIW, I think that problematic TLS variable in LLDB was moved/simplified in the 14.0.0 release, so this issue should no longer pop up, even if the underlying issue with external TLS + LTO probably still remains.
FWIW, I think that problematic TLS variable in LLDB was moved/simplified in the 14.0.0 release, so this issue should no longer pop up, even if the underlying issue with external TLS + LTO probably still remains.
Yeah, you made this change to workaround GCC/binutils: https://github.com/llvm/llvm-project/commit/7106f588567b59acb17c77f6116ba433b6226333
