"File too big/too many sections" when building Registry.cpp in MSYS2 Environment

Hello all,

I'm (re)building a copy of Clang 3.9 for a git fork of LLVM (or1k) that tracks 3.9 but is not yet merged into LLVM proper. The last merge from the main Clang codebase was on Aug 11, release_39. When building, LLVM seems to compile fine. However, with Clang I am running into the following error as shown in this gist: llvm-err.txt · GitHub

Just to test, I have also confirmed that this same error occurs as of commit 54f5752c, release_39 branch, on the LLVM Github mirror. I have not tried HEAD of master, or SVN r290090 as of this writing. I also have not tried compiling an LLVM/Clang using MSVC, and am not currently in a position to try.

According to this linked post, this error has occurred during Windows builds before: http://lists.llvm.org/pipermail/cfe-dev/2013-June/030024.html I know a stopgap solution is to introduce the –bigobj flag to the linker, but I was under the impression from another linked post- http://lists.llvm.org/pipermail/llvm-dev/2014-May/072642.html- that the flag should not be required, and some unit tests fail when –bigobj is enabled.

Are the above posts out of date, and the flag is now required? Are there any special options (besides overriding LDFLAGS directly) I may have forgot when generating the Makefiles? Building a Release build is not desirable for me for various reasons. My current LLVM/Clang, built in much the same way, is 3.5, so I know that in the past, too many sections wasn't an issue :).

Thanks for any help in advance! Sincerely,

Hallo William,

a few days ago I ran into the same problem when updating to 3.9. Compiling with option '-Og' did the trick for me.

My GCC version is:

$ g++ --version
g++.exe (Rev2, Built by MSYS2 project) 6.2.0

Frank

We need to fix the build to pass -mbig-obj to the gnu assembler. You can probably use -DCMAKE_CXX_FLAGS=-Wa,-mbigobj to work around the problem.

I’d add this flag to the llvm build myself, but my mingw64 build of clang is currently broken for other reasons.

Registry.cpp in MSYS2 Environment

We need to fix the build to pass -mbig-obj to the gnu assembler. You can probably use -DCMAKE_CXX_FLAGS=-Wa,-mbigobj to work around the problem.

So officially, Clang builds now require COFF big objects?

I'd add this flag to the llvm build myself, but my mingw64 build of clang is currently broken for other reasons.

Not that I'm qualified to fix it, but... what's wrong with the build?

We need to fix the build to pass -mbig-obj to the gnu assembler. You can

probably use -DCMAKE_CXX_FLAGS=-Wa,-mbigobj to work around the problem.

So officially, Clang builds now require COFF big objects?

Basically, yes. MSVC has the same limitation, and here are all the places
we add /bigobj now:

$ git grep '\/bigobj'
lib/ASTMatchers/Dynamic/CMakeLists.txt:
set_source_files_properties(Registry.cpp PROPERTIES COMPILE_FLAGS /bigobj)
lib/Sema/CMakeLists.txt: set_source_files_properties(SemaExpr.cpp
PROPERTIES COMPILE_FLAGS /bigobj)
test/Driver/cl-options.c:// RUN: /bigobj \
unittests/ASTMatchers/CMakeLists.txt:
set_source_files_properties(InternalASTMatchersTest.cpp PROPERTIES
COMPILE_FLAGS /bigobj)
unittests/ASTMatchers/CMakeLists.txt:
set_source_files_properties(NodeMatchersTest.cpp PROPERTIES COMPILE_FLAGS
/bigobj)
unittests/ASTMatchers/CMakeLists.txt:
set_source_files_properties(NarrowingMatchersTest.cpp PROPERTIES
COMPILE_FLAGS /bigobj)
unittests/ASTMatchers/CMakeLists.txt:
set_source_files_properties(ASTTraversalMatchersTest.cpp PROPERTIES
COMPILE_FLAGS /bigobj)
unittests/Tooling/CMakeLists.txt:
set_source_files_properties(RecursiveASTVisitorTest.cpp PROPERTIES
COMPILE_FLAGS /bigobj)
unittests/Tooling/CMakeLists.txt:
set_source_files_properties(RecursiveASTVisitorTestExprVisitor.cpp
PROPERTIES COMPILE_FLAGS /bigobj)

The problem is particularly bad on Win64 because every C++ function gets
separate .pdata and .xdata sections, although I don't think GCC does
separate .debug_* sections for every inline function like MSVC. So, if you
get close to 2**16/3 or 21845 functions in one file, it's easy to pass this
limit. RecursiveASTVisitor uses CRTP, which makes it pretty easy to hit
this limit.

I'd add this flag to the llvm build myself, but my mingw64 build of clang

is currently broken for other reasons.

Not that I'm qualified to fix it, but... what's wrong with the build?

We should pass -mbig-obj so that users don't have to.

To follow up, r290358 should fix this.

Sorry for the delay. I noticed that you pass the assembler options for only 64-bit builds. Is there any harm for enabling the flags for 32-bit builds as well? The 64-bit MinGW build appears to be broken on my machine (gcc 5.3.0); LTO.dll spent 30 minutes compiling before I manually disabled the build.

Did you cross-compile for MinGW? I've noticed that with the new change, native compile, Registry.cpp now compiles, but attempting to link
bin\clangDynamicASTMatchers.dll causes a link step that takes over 90 minutes (!!) before bombing with an excessive number of undefined symbols. So many, that I cannot even copy and paste them all from my scrollback. The linker cannot find any of the symbols from Registry.cpp.

It is dawning on me that building a Debug build of Clang/LLVM on Windows is impractical/development seems to mainly be done w/ gold on Linux to avoid linker woes.

1. Big-obj support in Binutils was absolutely broken till recently (see my ticket 19440 – COFF handling bug. In particular, renders bigobj support broken.).
Thus you need relatively fresh version of binutils to get things working (and they really work now).

2. Binutils do *not* support big-obj for 32-bit COFF target, thus it is *impossible* to debug build 32-bit hosted clang with GNU toolchain.

3. I believe, we should pay more attention to support self-hosted mingw-w64 clang, I maintain a couple of patches which allow me to build it, but I never tried to publish them, because I saw no interest. Btw, that recent LLVM patch introducing big-obj switch (https://github.com/llvm-mirror/llvm/commit/e1c9f504c6810be782714b8b39f11579e50fa5c7) also breaks self-hosted clang because gnu clang driver doesn't understand -Wa,-mbig-obj option. AFAIUI, LLVM handles COFF format automatically, selecting bigobj format if necessary, and msvc clang driver simply ignores '/bigobj' flag. I have a patch fixing gnu driver too.

Kyra

Sorry for the delay. I noticed that you pass the assembler options for
only 64-bit builds. Is there any harm for enabling the flags for 32-bit
builds as well? The 64-bit MinGW build appears to be broken on my machine
(gcc 5.3.0); LTO.dll spent 30 minutes compiling before I manually disabled
the build.

32-bit builds don't create as many sections for every inline function as
64-bit builds do because they don't use .pdata and .xdata, so I was hoping
it was not needed.

Did you cross-compile for MinGW?

No. One day I'll try it, but today is not that day. :slight_smile:

I've noticed that with the new change, native compile, Registry.cpp now
compiles, but attempting to link
bin\clangDynamicASTMatchers.dll causes a link step that takes over 90
minutes (!!) before bombing with an excessive number of undefined symbols.
So many, that I cannot even copy and paste them all from my scrollback. The
linker cannot find any of the symbols from Registry.cpp.

I also noticed it was very painful to link debug builds on Windows. I don't
think I actually attempted to link clang to confirm my fix, I only built
LLVM. I think it's slow for two reasons:
1. ld-bfd is really slow already, and slower when making PE files
2. DWARF symbols are impractically large

You can try building with less debug information (-g0) to speed things up.
If building with clang, you can use -gline-tables-only for the same purpose.

Anyway, I'll try linking clang to see if I can reproduce the Registry.cpp
link error.

It is dawning on me that building a Debug build of Clang/LLVM on Windows is

impractical/development seems to mainly be done w/ gold on Linux to avoid
linker woes.

The MSVC debug build is better supported, if that's an option for you.

I'm happy to review these kinds of patches if you want to CC me on them. I
don't have a lot of time to dedicate to mingw support in clang, so I mostly
apply other people's patches and confirm that things seem to work.

Accepting and ignoring the -mbig-obj flag in clang seems totally reasonable
to me. Our assembler should implicitly do the right thing, as you described.

Hi, Reid,

Thanks for being so responsive. I've attached the patch. It happens in a different place than MSVC's one, since the MSVC has it's own CLCompatOptions.td, which GNU driver doesn't have.

Cheers, Kyra

clang_bigobj_option_ignore.patch (533 Bytes)

Thanks, r290979