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

[Baesken, Matthias]

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