build: disable -stack-clash-protection on Windows #19318

fanquake · 2020-06-18T13:41:39Z

This does not currently work properly, and will cause GCC to terminate while compiling for Windows. This affects x86_64-w64-mingw32-g++ 8 through 10. Related upstream issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458.

I've PR'd this separate to #18921, as this doesn't have to wait for us to decide if we want to opt-in to using those flags on other platforms, and is causing build failures.

While doing more testing for #18921, I (and the bot) saw build issues that would terminate GCC:

  CXX      bitcoind-bitcoind.o
during RTL pass: final
In file included from ./logging.h:10,
                 from ./util/system.h:21,
                 from ./init.h:11,
                 from bitcoind.cpp:13:
./tinyformat.h: In static member function 'static int tinyformat::detail::FormatArg::toIntImpl(const void*) [with T = std::__cxx11::basic_string<char>]':
./tinyformat.h:550:9: internal compiler error: in seh_emit_stackalloc, at config/i386/winnt.c:1043
         }
         ^
0x7fa20389609a __libc_start_main
	../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
{standard input}: Assembler messages:
{standard input}: Error: open SEH entry at end of file (missing .seh_endproc)

Here's a fairly minimal test case, that will cause the issue using -fstack-clash-protection -O1:

#include <stdexcept>

// tested with
// x86_64-w64-mingw32-g++ (GCC) 8.3-posix 20190406 (Debian)
// x86_64-w64-mingw32-g++ (GCC) 9.3.0 (macOS)
// x86_64-w64-mingw32-g++ (GCC) 10-posix 20200525 (Debian)

class _error: public std::runtime_error {
public:
    _error(const std::string &what): std::runtime_error(what) {}
};

void crash() {
    throw _error("Some crash!");
}

int main() {
    crash();
    return 0;
}

x86_64-w64-mingw32-g++ test.cpp -fstack-clash-protection -O1

Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/10-posix/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --with-headers=/usr/x86_64-w64-mingw32/include --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto --enable-threads=posix --program-suffix=-posix --program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 --with-as=/usr/bin/x86_64-w64-mingw32-as --with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic --enable-libstdcxx-filesystem-ts=yes --enable-dependency-tracking
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10-posix 20200525 (GCC) 
COLLECT_GCC_OPTIONS='-fstack-clash-protection' '-O1' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-w64-mingw32/10-posix/cc1plus -quiet -v -D_REENTRANT test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -O1 -version -fstack-clash-protection -o /tmp/ccer6MYu.s
GNU C++14 (GCC) version 10-posix 20200525 (x86_64-w64-mingw32)
	compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/lib/gcc/x86_64-w64-mingw32/10-posix/../../../../x86_64-w64-mingw32/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-w64-mingw32/10-posix/include/c++
 /usr/lib/gcc/x86_64-w64-mingw32/10-posix/include/c++/x86_64-w64-mingw32
 /usr/lib/gcc/x86_64-w64-mingw32/10-posix/include/c++/backward
 /usr/lib/gcc/x86_64-w64-mingw32/10-posix/include
 /usr/lib/gcc/x86_64-w64-mingw32/10-posix/include-fixed
 /usr/lib/gcc/x86_64-w64-mingw32/10-posix/../../../../x86_64-w64-mingw32/include
End of search list.
GNU C++14 (GCC) version 10-posix 20200525 (x86_64-w64-mingw32)
	compiled by GNU C version 10.1.0, GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c42c71f75c7bf48c403bd1b5d143d4a1
during RTL pass: final
test.cpp: In function 'int main()':
test.cpp:17:1: internal compiler error: in seh_emit_stackalloc, at config/i386/winnt.c:1043
   17 | }
      | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

This does not currently work properly, and will cause GCC to terminate while compiling bitcoind. Related upstream issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458

laanwj · 2020-06-18T14:35:47Z

configure.ac

+
+       dnl stack-clash-protection does not work on Windows
+       dnl https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458
+       AX_CHECK_COMPILE_FLAG([-fno-stack-clash-protection],[HARDENED_CXXFLAGS="$HARDENED_CXXFLAGS -fno-stack-clash-protection"])


Wouldn't it be preferable in this case to not add it in the first place, instead of append -fno-X here? Or is it enabled by some umbrella option?

I think it's likely we'll end up enabling this, and other flags (for other platforms) in #18921. Progress there has been slow, so I wanted to split this out and just disable it now. It doesn't work, and is causing build failures when testing 18921 and related PRs. I haven't seen it being turned on by an umbrella type option/compiler default yet.

What I mean is making the AC_CHECK_COMPILE_FLAG(…) to enable it conditional on non-windows.

Otherwise you get a gcc overall command line like

fstack-clash-protection … … fno-stack-clash-protection

which probably workd but is confusing to see.

I agree with @wumpus. It sounds like this combo would fail to compile even the most trivial c++ program, so I can't imagine anyone shipping a mingw compiler with this on by default. So proactively turning it of seems like overkill.

Instead, how about for #18921, we add a your minimal test-case as the last (input) param to AX_CHECK_COMPILE_FLAG. That way we don't have to special-case it, and it may just work on mingw at some point in the future.

I've merged this into #18921.

wumpus · 2020-06-18T22:52:17Z

Wrong @wumpus.

build: disable -stack-clash-protection on Windows

bb341ce

This does not currently work properly, and will cause GCC to terminate while compiling bitcoind. Related upstream issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458

fanquake added the Build system label Jun 18, 2020

laanwj reviewed Jun 18, 2020

View reviewed changes

fanquake closed this Jun 19, 2020

fanquake mentioned this pull request Jun 19, 2020

build: add stack-clash and control-flow protection options to hardening flags #18921

Merged

bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022

fanquake deleted the disable_stack_clash_windows branch November 9, 2022 16:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

build: disable -stack-clash-protection on Windows #19318

build: disable -stack-clash-protection on Windows #19318

Uh oh!

fanquake commented Jun 18, 2020

Uh oh!

laanwj Jun 18, 2020

Uh oh!

fanquake Jun 18, 2020

Uh oh!

laanwj Jun 18, 2020 •

edited

Loading

Uh oh!

theuni Jun 18, 2020

Uh oh!

fanquake Jun 19, 2020

Uh oh!

wumpus commented Jun 18, 2020

Uh oh!

Uh oh!

build: disable -stack-clash-protection on Windows #19318

build: disable -stack-clash-protection on Windows #19318

Uh oh!

Conversation

fanquake commented Jun 18, 2020

Uh oh!

laanwj Jun 18, 2020

Choose a reason for hiding this comment

Uh oh!

fanquake Jun 18, 2020

Choose a reason for hiding this comment

Uh oh!

laanwj Jun 18, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

theuni Jun 18, 2020

Choose a reason for hiding this comment

Uh oh!

fanquake Jun 19, 2020

Choose a reason for hiding this comment

Uh oh!

wumpus commented Jun 18, 2020

Uh oh!

Uh oh!

laanwj Jun 18, 2020 •

edited

Loading