The current plan is to just disable FORTIFY_SOURCE entirely in JDK-8050803. The FORTIFY_SOURCE implementation is just causing too many problems relative to it's potential benefit.
Mike On Jul 29 2014, at 06:37 , Andrew Haley <[email protected]> wrote: > In a fastdebug build of JDK9: > > Compiling ../generated/jvmtifiles/bytecodeInterpreterWithChecks.cpp > rm -f bytecodeInterpreterWithChecks.o > /home/aph/gcc/trunk/install/bin//g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT > -I. -I/scratch/jdk9/hotspot/src/share/vm/prims > -I/scratch/jdk9/hotspot/src/share/vm > -I/scratch/jdk9/hotspot/src/share/vm/precompiled > -I/scratch/jdk9/hotspot/src/cpu/x86/vm > -I/scratch/jdk9/hotspot/src/os_cpu/linux_x86/vm > -I/scratch/jdk9/hotspot/src/os/linux/vm > -I/scratch/jdk9/hotspot/src/os/posix/vm -I../generated > -DHOTSPOT_BUILD_USER="\"aph\"" -DHOTSPOT_LIB_ARCH=\"amd64\" > -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 > -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 > -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 > -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new > -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -fno-omit-frame-pointer > -O0 -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all --param > ssp-buffer-size=1 -D_NMT_NOINLINE_ -DVM_LITTLE_ENDIAN -D_LP64=1 -Wno-error > -Wpointer-arith -Wsign-compare -Wundef ! > -Wunused-f > unction -Wunused-value -DDTRACE_ENABLED -c -MMD -MP -MF > ../generated/dependencies/bytecodeInterpreterWithChecks.o.d -fpch-deps -o > bytecodeInterpreterWithChecks.o > ../generated/jvmtifiles/bytecodeInterpreterWithChecks.cpp > In file included from /usr/include/stdio.h:27:0, > from /scratch/jdk9/hotspot/src/share/vm/prims/jni.h:39, > from > /scratch/jdk9/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp:28, > from > /scratch/jdk9/hotspot/src/share/vm/utilities/globalDefinitions.hpp:33, > from > /scratch/jdk9/hotspot/src/share/vm/utilities/debug.hpp:28, > from > /scratch/jdk9/hotspot/src/share/vm/runtime/globals.hpp:28, > from > /scratch/jdk9/hotspot/src/share/vm/memory/allocation.hpp:28, > from /scratch/jdk9/hotspot/src/share/vm/utilities/utf8.hpp:28, > from /scratch/jdk9/hotspot/src/share/vm/oops/symbol.hpp:28, > from > /scratch/jdk9/hotspot/src/share/vm/classfile/vmSymbols.hpp:28, > from > /scratch/jdk9/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:26, > from > ../generated/jvmtifiles/bytecodeInterpreterWithChecks.cpp:3: > /usr/include/features.h:327:4: error: #warning _FORTIFY_SOURCE requires > compiling with optimization (-O) [-Wcpp] > # warning _FORTIFY_SOURCE requires compiling with optimization (-O) > ^ > This is quite tricky to fix. It means that we either have to do > without treating CPP warnings as hard errors or find some way to deal > with setting the _FORTIFY_SOURCE level on files where optimization is > set to -O0. > > Any ideas? maybe this? > > Andrew. > > > diff -r e90276b4908c make/linux/makefiles/gcc.make > --- a/make/linux/makefiles/gcc.make Fri Jul 25 15:38:08 2014 -0700 > +++ b/make/linux/makefiles/gcc.make Tue Jul 29 14:35:17 2014 +0100 > @@ -214,7 +214,7 @@ > WARNINGS_ARE_ERRORS += -Wno-return-type -Wno-empty-body > endif > > WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef -Wunused-function > -Wunused-value -Wformat=2 > > ifeq ($(USE_CLANG),) > # Since GCC 4.3, -Wconversion has changed its meanings to warn these > implicit > @@ -230,8 +230,8 @@ > CFLAGS_WARN/BYFILE = $(CFLAGS_WARN/$@)$(CFLAGS_WARN/DEFAULT$(CFLAGS_WARN/$@)) > > # optimization control flags (Used by fastdebug and release variants) > -OPT_CFLAGS/NOOPT=-O0 > -OPT_CFLAGS/DEBUG=-O0 > +OPT_CFLAGS/NOOPT=-O0 -Wno-error=cpp > +OPT_CFLAGS/DEBUG=-O0 -Wno-error=cpp > OPT_CFLAGS/SIZE=-Os > OPT_CFLAGS/SPEED=-O3 > > @@ -339,7 +339,7 @@ > endif > > # Allow no optimizations. > -DEBUG_CFLAGS=-O0 > +DEBUG_CFLAGS=-O0 -Wno-error=cpp > > # DEBUG_BINARIES uses full -g debug information for all configs > ifeq ($(DEBUG_BINARIES), true) > >
