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

[David Holmes]

On 12/03/2014 7:12 AM, Vladimir Kozlov wrote:
> 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.

Though we are very inconsistent about whether things go in those files 
or in the compiler specific ones. You either have to put compiler 
conditionals in the debug/fastdebug files, or else debug/fastdebug 
conditionals in the compiler .make files.

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

What are you referring to? A "normal" hotspot build starts with 
make/Makefile. A developer on platform X may kick of a build using 
make/X/Makefile (though we need to wean them off that). A top-level 
configure-based build will also use make/Makefile.

David

> 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
>>