Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

[Erik Joelsson]

Hello,

I just tried this and you are correct. However, it does seem to work if 
you instead use -U_FORTIFY_SOURCE.

/Erik

On 2019-05-09 05:36, Baesken, Matthias wrote:
Hi Erik, while  setting -O<x>  and -O<y>  (with x != y )   in one gcc/g++  
command line call  works ,
   setting  together  -D_FORTIFY_SOURCE=2  and   -D_FORTIFY_SOURCE=0   in one 
command line call  generates a warning , so I think we cannot do that .


Best regards, Matthias
  

Hello Matthias,

On 2019-05-08 06:27, Baesken, Matthias wrote:
Hello,    I looked a bit  more  into it .
It seems to me ,  that   when  -ffp-contract=off   is available  which is the
case with  current gcc versions ,  we want to optimize the 2 special files (
sharedRuntimeTrig.cpp / sharedRuntimeTrans.cpp ).
   see the following comments :

jdk/make/hotspot/lib/JvmOverrideFiles.gmk

47# If the FDLIBM_CFLAGS variable is non-empty we know
48# that the fdlibm-fork in hotspot can get optimized
49# by using -ffp-contract=off on GCC/Clang platforms.
    ......
58  BUILD_LIBJVM_sharedRuntimeTrig.cpp_CXXFLAGS := -DNO_PCH
$(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG)
59  BUILD_LIBJVM_sharedRuntimeTrans.cpp_CXXFLAGS := -DNO_PCH
$(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG)
60
Will this not just resolve itself if you also add -D_FORTIFY_SOURCE=0 to
C_O_FLAG_NONE (and all the other optimization flag variables that have
the value "-O0")?
But still, setting both -O3 and -O2  in one compile call looks not nice to me .
This may not look nice, but is how we have to do things. The last flag
on a compiler command line takes precedence. We rely on this to override
general flags with more specific ones (typically a general flag for the
whole library with specific ones for certain compilation units). This
technique is quite common.
In case of  ancient gcc  ***without***  -ffp-contract=off   ,  we might still
run into issues for these  2 special files  when _FORTIFY_SOURCE  is set .
Don't know if this is  still relevant .
In case  we want to be on the very safe side , we might  need  to  filter out
-D_FORTIFY_SOURCE=2    for these 2 compilation units .

We don't want to filter out flags. It creates very brittle code that is
likely to break in the future.

For the patch, I think it would make sense to introduce a variable for
the value -D_FORTIFY_SOURCE=2 (and
-D_FORTIFY_SOURCE=0/-U_FORTIFY_SOURCE) to avoid repeating it.

/Erik