For the Open record, the hotspot fix has an issue because
FASTDEBUG_CFLAGS is unused on linux/bsd.
David
On 9/05/2014 2:07 PM, David Holmes wrote:
Hi Mike,
This looks okay to me, but of course the proof is in the building and
testing.
David
On 4/05/2014 1:24 PM, Mike Duigou 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
