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

[Vladimir Kozlov]

On 3/12/14 2:57 AM, David Holmes wrote:
> 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.

DBG is defined in JDK make files only:

common//autoconf/generated-configure.sh:      VARIANT="DBG"
common//autoconf/generated-configure.sh:      VARIANT="DBG"
common//autoconf/hotspot-spec.gmk.in:# Legacy setting: OPT or DBG
common//autoconf/jdk-options.m4:      VARIANT="DBG"
common//autoconf/jdk-options.m4:      VARIANT="DBG"

But when we build Hotspot standalone we don't use or even have those 
files. So we should not check DBG in Hotspot's makefiles.

Thanks,
Vladimir

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