Ping. Still needing reviewers on this issue. I plan to push this change through the hotspot-rt repo.
Mike On May 3 2014, at 20:24 , Mike Duigou <mike.dui...@oracle.com> wrote: > Hello; > > Finally getting back to this issue I have done some cleanup and adjusted the > hotspot gcc.make files to use VARIANT rather than DEBUG_LEVEL. > > This version also add support for the "-fsanitize=undefined" undefined > behaviour warnings feature when it is available (Clang and GCC 4.9). The > code to emit the option has been added for Clang but I haven't yet added test > for the option's availability under Clang so currently it will be enabled > only for GCC. > > https://bugs.openjdk.java.net/browse/JDK-8032045 > http://cr.openjdk.java.net/~mduigou/JDK-8032045/6/webrev/ > > Mike > > On Mar 11 2014, at 05:47 , Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> > wrote: > >> On 2014-03-11 00:49, Mike Duigou wrote: >>> I have updated the patch to respond to Magnus's feedback and to accommodate >>> intervening changes to the configure and hotspot make files. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ >>> >>> This version is, hopefully, almost ready to be pushed. >> >> I have only glanced at the hotspot build changes and can't really say >> anything about them. The hotspot team still owns these; I'm cc:ing them now. >> >> The top-level build changes looks fine. Thank you Mike for cleaning things >> up! >> >> /Magnus >> >>> >>> Mike >>> >>> On Feb 20 2014, at 15:43 , Mike Duigou <mike.dui...@oracle.com> wrote: >>> >>>> Hello all; >>>> >>>> This issue is a followon to JDK-8030350 >>>> (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the >>>> compiler warnings used for compiling native code. The proposed changes >>>> principally impact the Linux platform. >>>> >>>> While 8030350 was focused on compiler warnings which did not impact code >>>> generation, this changeset will, for some configurations, change the >>>> native code generated and likely change performance. These proposed option >>>> changes prevent specific types of relocation table, stack and heap memory >>>> corruption in native code. Preventing these types of memory corruption may >>>> be useful for finding certain kinds of bugs though and do provide some >>>> minimal additional protections against malicious attacks. They aren't, by >>>> any means, a substitute for following appropriate secure coding guidelines. >>>> >>>> The rationale behind the implementation is as follows. For release builds >>>> during the initial phase of JDK 9 I would like to enable only compile time >>>> checks. This ends up being similar to the warnings in JDK-8030350. These >>>> options have no runtime impact on footprint or performance and very >>>> minimal additional compile time cost while providing value. **Release >>>> builds are not expected to see any performance or footprint change as a >>>> result of this changeset** >>>> >>>> For fast debug builds we can enable linker protections (relro) and static >>>> compile time bounds checks (FORTIFY_SOURCE=1). FORTIFY_SOURCE=1 might be >>>> moved to the production builds as well because it has no runtime cost or >>>> executable size cost. >>>> >>>> For slow debug builds we can enable full linker protection (at a potential >>>> cost in startup time), runtime bounds checks and stack protection >>>> (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely enable >>>> -fprotect-stack-strong when available in GCC 4.9 >>>> >>>> The basis for enabling the additional protections in debug builds is that >>>> it will help us find bugs in our native code and we aren't as concerned in >>>> debug builds with footprint and performance. Since many developers already >>>> do their personal builds in fastdebug or slowdebug mode for testing this >>>> will provide good opportunity to shake out any problems with the options >>>> while not impacting release builds. Should we find that any of the options >>>> provide significant value for their cost we can move them to fastdebug or >>>> release. If any of the options prove too costly they can be demoted or >>>> removed entirely. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ >>>> >>>> Additional to enabling the various compiler options I attempted to >>>> rationalize some of the skew between the various >>>> hotspot/make/{platform}/makefiles/gcc.make files while avoiding changing >>>> existing behaviour. I have also introduced the new -Og "optimize for >>>> debugging" option and there are now an explicit C{XX}_O_FLAG_DEBUG >>>> definitions to complement the C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} >>>> optimization options. >>>> >>>> Thanks, >>>> >>>> Mike >> >
