Windows build failure with -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS: too many symbols exported

[glandium]

Issue #56109 is back.

$ wc -l ./tools/clang/tools/clang-repl/clang-repl.symbols
66002 ./tools/clang/tools/clang-repl/clang-repl.symbols

It's worth noting that the link.exe error is almost inscrutable (LINK : fatal error LNK1189: library limit of 65535 objects exceeded), while the llvm-link.exe error is more useful (lld-link: error: too many exported symbols (got 66002, max 65535))

Random observation: there are 3k+ symbols __xmm@something that are exported, and I'm not sure they need to be.

The number is also different between cross and native compiles (66002 vs. 66119)

It's also worth noting that clang.def is approaching the limit too, with 64420 lines.

The clang-repl.def from my cross build can be found here: https://gist.githubusercontent.com/glandium/79352c2fb0cc63589a3b308a0b25b0f6/raw/0f2e4586baade767df4f0f4c68a2e7c63522ca7d/clang-repl.def

[syheliel]

What's your build command? Maybe you can try to use Visual studio to open the CmakeLists.txt as a cmake project. I have found that it's a better way than using cmd, becuase visual studio will take care of the compiler settings.

[glandium]

I don't see what difference using VS would make, considering the creation of the .symbols/.def files roots in LLVM's CMakeLists.txt files.

The full cmake command line (off our CI) looks like this:
cmake -GNinja -DCMAKE_C_COMPILER=Z:/task_167450704269412/fetches/vs/VC/Tools/MSVC/14.29.30133/bin/hostx64/x64/cl.exe -DCMAKE_CXX_COMPILER=Z:/task_167450704269412/fetches/vs/VC/Tools/MSVC/14.29.30133/bin/hostx64/x64/cl.exe -DCMAKE_ASM_COMPILER=Z:/task_167450704269412/fetches/vs/VC/Tools/MSVC/14.29.30133/bin/hostx64/x64/ml64.exe -DCMAKE_AR=Z:/task_167450704269412/fetches/vs/VC/Tools/MSVC/14.29.30133/bin/hostx64/x64/lib.EXE -DCMAKE_C_FLAGS= -DCMAKE_CXX_FLAGS= -DCMAKE_ASM_FLAGS= -DCMAKE_EXE_LINKER_FLAGS= -DCMAKE_SHARED_LINKER_FLAGS= -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=Z:\task_167450704269412\fetches\llvm-project/build/stage1/clang -DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64;WebAssembly -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF -DLLVM_ENABLE_ASSERTIONS=OFF -DLLVM_ENABLE_BINDINGS=OFF -DLLVM_ENABLE_CURL=OFF -DLLVM_INCLUDE_TESTS=OFF -DCLANG_REPOSITORY_STRING=taskcluster-ceyNDvLCSYGz3AEyYZwtzg -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON -DLLVM_USE_CRT_RELEASE=MT -DLLVM_ENABLE_PROJECTS=clang;lld;clang-tools-extra Z:\task_167450704269412\fetches\llvm-project/llvm

The only thing that I expect to be making a difference is -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON.

[glandium]

I managed to fix the clang-repl failure by adding some filtering in extract_symbols.py (for __real@* and __xmm@* symbols, which are constants that presumably plugins would pick from headers), but that failure still happens on clang itself, except when building with clang itself, and the main difference there is that clang and cl are not exporting the same (trivial) functions that are defined in headers (because they don't inline the same set). Ironically, these are symbols plugins would not really need (because they would either inline from the headers or end up defining it themselves), but I don't think they could be distinguished in the output from dumpbin or llvm-readobj.