RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds

[Vladimir Kozlov]

Mike,

About hotspot makefiles changes. There is no DBG variant in hotspot:

ifeq ($(VARIANT), DBG)

We have specialized makefiles debug.make and fastdebug.make you can used 
for such settings.

Note, normal Hotspot build (at least now) does not invoke top level make 
files.

I would suggest to run JPRT hotspot test job (-stree . from hotspot 
repo). And also JDK control build with -buildenv SKIP_BOOT_CYCLE=false.

Thanks,
Vladimir

On 3/11/14 5:47 AM, Magnus Ihse Bursie 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.duigou at 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
>