mingw-w64 win64 build crashes tblgen.exe on Target/CellSPU

[rubenvb]

Bugzilla Link	8850
Resolution	WONTFIX
Resolved on	Apr 22, 2011 02:58
Version	trunk
OS	Windows NT
Blocks	llvm/llvm-bugzilla-archive#9072
CC	@asl,@rubenvb

Extended Description

A build using a mingw-w64 toolchain targetting Windows x64 from mingw-w64.sourceforge.net crashes tblgen when building the Target/CellSPU. A backtrace reveals very little:

#​0 0x000000006ceceead in libgcc_s_sjlj-1!_Unwind_SjLj_Register () from M:\Development\mingw64\bin\libgcc_s_sjlj-1.dll
#​1 0x0000000000000000 in ?? ()

Even when compiled with debug level -g3

Disabling this Target allows the build to continue.

PS: you will need the patch from this bug report to work around a triviality: http://llvm.org/bugs/show_bug.cgi?id=8848

[asl]

Looks like it was miscompiled by your gcc. What was the version of gcc used?

[rubenvb]

It's GCC 4.5.2 (stable branch snapshot).

Here's the link to the download files:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_20101002/

Remember they produce x64 Windows code, so if you want to test, you'll need x64 Windows.

[asl]

Ok, what if you try dw2 version of the toolchain?

[rubenvb]

64-bit GCC for Windows only has a sjlj version. dw2 was inherently broken and pretty much unfixable for x64 Windows, and not implemented/used. Future versions of GCC will hopefully get something better than either (SEH, dwarf4? and the like), but for now that's a no go...

I have contacted the mingw-w64 project, and awaiting their response.

The 32-bit mingw-w64 (confusing isn't it?) sjlj toolchain does not exhibit this behavior.

[asl]

What if you increase the stack size of the tblgen?

[rubenvb]

How would I do that?

Thanks for the continued interest.

[asl]

Well, normally you pass some additional stuff to linker, e.g.: gcc -Wl,--stack,16777216 -o file.exe file.c

[rubenvb]

Adding the exact option you showed produced a non-crashing tblgen for the CellSPU portion of LLVM.

Can this be fixed in the build system?

Thanks!

[llvmbot]

It seems it can be reproduced with mingw-w64-20110207.

[llvmbot]

It happens also on "clang -O0".

I will add this issue to the release notes.

--
On mingw-w64, you should add a flag to the configurator, if you met tblgen.exe crash when you configured with --target=CellSPU (or --target=all).

eg. /path/to/configure --enable-targets=all LDFLAGS=-Wl,--stack,16777216
(I have not checked with cmake yet.)

[llvmbot]

Add a note to GettingStarted.html in r128404.

[rubenvb]

simple cmake patch for 64-bit mingw build fix
I have added a simple Cmake patch to resolve around the issue. It detects Win64 using void* size which is 8 on Win64, and this check is in an already-present if( MINGW ) block, so it only affects x86_64-w64-mingw32 (and perhaps in the distant future x86_64-pc-mingw32, if mingw.org ever gets a 64-bit compiler).

I'd like this applied, because with Cmake it's not straightforward to add this option, and it's better to have it only enabled for the tblgen target.

[llvmbot]

I have added a simple Cmake patch to resolve around the issue. It detects Win64
using void* size which is 8 on Win64, and this check is in an already-present
if( MINGW ) block, so it only affects x86_64-w64-mingw32 (and perhaps in the
distant future x86_64-pc-mingw32, if mingw.org ever gets a 64-bit compiler).

Would it be possible on x86_64-linux?

[llvmbot]

Would it be possible on x86_64-linux?

Doh! linux should not be affected here!

Would it be not enough to tweak global LDFLAGS?

[rubenvb]

Would it be possible on x86_64-linux?

Doh! linux should not be affected here!

Would it be not enough to tweak global LDFLAGS?

That would also work, but affect everything at once. I don't think that's ideal, as tblgen is the only part affected by this bug. Frankly, I like my solution better. It is much more localized and easier for the user. Makes everything work "out of the box" so to speak. Perhaps a comment to this bug wouldn't hurt in the Cmake file, so future generations who care can see why it was done.