Integrated: 8248584: Enable CHECK_UNHANDLED_OOPS for Windows fastdebug builds

On Tue, 19 Oct 2021 19:21:24 GMT, Harold Seigel wrote: > Please review this small change to enable CHECK_UNHANDLED_OOPs for Windows > fastdebug builds. The change was tested by running Mach5 tiers 1-6 on > Windows-x64-debug. > > Thanks, Harold This pull request has now

Re: RFR: 8248584: Enable CHECK_UNHANDLED_OOPS for Windows fastdebug builds

On Tue, 19 Oct 2021 19:21:24 GMT, Harold Seigel wrote: > Please review this small change to enable CHECK_UNHANDLED_OOPs for Windows > fastdebug builds. The change was tested by running Mach5 tiers 1-6 on > Windows-x64-debug. > > Thanks, Harold Thanks David and Erik! --

Re: RFR: 8248584: Enable CHECK_UNHANDLED_OOPS for Windows fastdebug builds

On Tue, 19 Oct 2021 19:21:24 GMT, Harold Seigel wrote: > Please review this small change to enable CHECK_UNHANDLED_OOPs for Windows > fastdebug builds. The change was tested by running Mach5 tiers 1-6 on > Windows-x64-debug. > > Thanks, Harold Looks good to me. -

Re: RFR: 8248584: Enable CHECK_UNHANDLED_OOPS for Windows fastdebug builds

On Tue, 19 Oct 2021 19:21:24 GMT, Harold Seigel wrote: > Please review this small change to enable CHECK_UNHANDLED_OOPs for Windows > fastdebug builds. The change was tested by running Mach5 tiers 1-6 on > Windows-x64-debug. > > Thanks, Harold Seems fine to me.

RFR: 8248584: Enable CHECK_UNHANDLED_OOPS for Windows fastdebug builds

Please review this small change to enable CHECK_UNHANDLED_OOPs for Windows fastdebug builds. The change was tested by running Mach5 tiers 1-6 on Windows-x64-debug. Thanks, Harold - Commit messages: - 8248584: Enable CHECK_UNHANDLED_OOPS for Windows fastdebug builds Changes

RE: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

gt; > >> -Original Message- > >> From: Erik Joelsson > >> Sent: Freitag, 10. Mai 2019 16:29 > >> To: Baesken, Matthias ; David Holmes > >> ; 'build-dev@openjdk.java.net' >> d...@openjdk.java.net> > >> Subject: Re: RFR: 81

Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

, Matthias ; David Holmes ; 'build-dev@openjdk.java.net' Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags Hello Matthias, I think just -U_FORTIFY_SOURCE should be enough to unset it, no need to also set it to

RE: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

openjdk.java.net' d...@openjdk.java.net> > Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - > was : RE: gcc FORTIFY_SOURCE application security flags > > Hello Matthias, > > I think just -U_FORTIFY_SOURCE should be enough to unset it, no need to > also set

Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

gt; 4.6 in jdk/jdk ) Best regards, Matthias -Original Message- From: Erik Joelsson Sent: Donnerstag, 9. Mai 2019 15:18 To: Baesken, Matthias ; David Holmes ; 'build-dev@openjdk.java.net' Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FOR

RE: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

used gcc's we are always > 4.6 in jdk/jdk ) > > > > Best regards, Matthias > > > > > >> -Original Message- > >> From: Erik Joelsson > >> Sent: Donnerstag, 9. Mai 2019 15:18 > >> To: Baesken, Matthias ; David Holmes > &g

Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

vid Holmes ; 'build-dev@openjdk.java.net' Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags Hello, I just tried this and you are correct. However, it does seem to work if you instead use -U_FORTIFY_SOURCE. /E

RE: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

enjdk.java.net> > Subject: Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - > was : RE: gcc FORTIFY_SOURCE application security flags > > Hello, > > I just tried this and you are correct. However, it does seem to work if > you instead use -U_FORTIFY_SOURCE. &

Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

Hello, I just tried this and you are correct. However, it does seem to work if you instead use -U_FORTIFY_SOURCE. /Erik On 2019-05-09 05:36, Baesken, Matthias wrote: Hi Erik, while setting -O and -O (with x != y ) in one gcc/g++ command line call works , setting together -D_FORT

RE: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

Hi Erik, while setting -O and -O (with x != y ) in one gcc/g++ command line call works , setting together -D_FORTIFY_SOURCE=2 and -D_FORTIFY_SOURCE=0 in one command line call generates a warning , so I think we cannot do that . Best regards, Matthias > Hello Matthias, > > O

Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

up containing both -O3 and a later, possible override, via the per-file settings. The -O3 flag originates from it being a release/fastdebug build. Thanks, Severin On Wed, 2019-05-08 at 13:27 +, Baesken, Matthias wrote: > Hello,I looked a bit more into it . > It seems to me , that

Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

he future. For the patch, I think it would make sense to introduce a variable for the value -D_FORTIFY_SOURCE=2 (and -D_FORTIFY_SOURCE=0/-U_FORTIFY_SOURCE) to avoid repeating it. /Erik Best regards, Matthias Hi David, thanks for the comment . Currently I do not see the issue in our fast

RE: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

the comment . > > Currently I do not see the issue in our fastdebug builds . > So I think the opt-flag filtering got changed/removed in the years after the > issues were reported . > > > https://bugs.openjdk.java.net/browse/JDK-8047952 > > mentions special O-leve

RE: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

Hi David, thanks for the comment . Currently I do not see the issue in our fastdebug builds . So I think the opt-flag filtering got changed/removed in the years after the issues were reported . https://bugs.openjdk.java.net/browse/JDK-8047952 mentions special O-level settings for

Re: RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

Hi Matthias, On 8/05/2019 6:05 pm, Baesken, Matthias wrote: Hello, here is a webrev, I used the existing bug "JDK-8130017 : use _FORTIFY_SOURCE in gcc fastdebug builds" Hope that’s fine . That is fine, but please add a comment to the bug explaining exactly how you fixed the

RFR: 8130017: use _FORTIFY_SOURCE in gcc fastdebug builds - was : RE: gcc FORTIFY_SOURCE application security flags

Hello, here is a webrev, I used the existing bug "JDK-8130017 : use _FORTIFY_SOURCE in gcc fastdebug builds" Hope that’s fine . https://bugs.openjdk.java.net/browse/JDK-8130017 http://cr.openjdk.java.net/~mbaesken/webrevs/8130017.0/ Our internal OpenJDK Linux (x86_64, ppc6

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

Since the question of how to get the stack pointer in hotspot is unexpectedly difficult, I propose we split into two separate changes and we can submit the make/ changes that Erik is happy with.

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

I see stack pointers (and frame pointers) declared as intptr_t* which makes no sense to me. These are all "just" pointers, so declare them as either void* or intptr_t or address In the construct below, we could elide the cast if we had declared esp right in the first place?! intptr_t* esp; _

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

There sure seems to be a lot of confusion about how many stack frames we're getting at the hot end of the stack, e.g. register intptr_t **fp __asm__ (SPELL_REG_FP); // fp is for this frame (_get_previous_fp). We want the fp for the // caller of os::current_frame*(), so go up two frames. How

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

(I keep trying not to become a hotspot engineer...) I would define current_stack_pointer as a macro using expression statements: prototype is: #if defined(__clang__) #define sp_3() ({ intptr_t rsp; __asm__ __volatile__ ("mov %% rsp, %0":"=r"(rsp):); rsp; }) #else #define sp_3() ({ register intptr

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

On Fri, Jun 22, 2018 at 1:57 PM, David Holmes wrote: > On 21/06/2018 10:37 PM, Thomas Stüfe wrote: >> >> On Thu, Jun 21, 2018 at 1:27 PM, David Holmes >> wrote: >>> >>> On 21/06/2018 10:05 AM, Martin Buchholz wrote: On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz >>>

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

On 21/06/2018 10:37 PM, Thomas Stüfe wrote: On Thu, Jun 21, 2018 at 1:27 PM, David Holmes wrote: On 21/06/2018 10:05 AM, Martin Buchholz wrote: On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz mailto:marti...@google.com>> wrote: Hi David and build-dev folk, After way too much buil

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

I see: Don't use // os::current_stack_pointer(), as its result can be slightly below current // stack pointer, causing us to not alloca enough to reach "bottom". If you really really want to get the stack pointer of the current frame, you can't put it in a function! Use magic compiler extens

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

On Thu, Jun 21, 2018 at 1:27 PM, David Holmes wrote: > On 21/06/2018 10:05 AM, Martin Buchholz wrote: >> >> On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz > > wrote: >> >> Hi David and build-dev folk, >> >> After way too much build/hotspot hacking, I have a be

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

On 21/06/2018 10:05 AM, Martin Buchholz wrote: On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz > wrote: Hi David and build-dev folk, After way too much build/hotspot hacking, I have a better fix: clang inlined os::current_stack_pointer into its caller _

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

On Wed, Jun 20, 2018 at 4:03 PM, Martin Buchholz wrote: > Hi David and build-dev folk, > > After way too much build/hotspot hacking, I have a better fix: > > clang inlined os::current_stack_pointer into its caller __in the same > translation unit___ (that could be fixed in a separate change) so o

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

Looks good to me. /Erik On 2018-06-20 16:49, Martin Buchholz wrote: Thanks Erik. On Wed, Jun 20, 2018 at 4:19 PM, Erik Joelsson mailto:erik.joels...@oracle.com>> wrote: Hello, It's very probable that we have made several such mistakes with our flags, since for the most part, w

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

Thanks Erik. On Wed, Jun 20, 2018 at 4:19 PM, Erik Joelsson wrote: > Hello, > > It's very probable that we have made several such mistakes with our flags, > since for the most part, we have a 1-1 mapping of compiler and OS. We > certainly appreciate correcting this whenever possible. I don't hav

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

OS_CFLAGS_JVM -mno-omit-leaf-frame-pointer -mstack-alignment=16" - fi - # Optional POSIX functionality needed by the JVM # # Check if clock_gettime is available and in which library. This indicates 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_align

Re: RFR: 8186780: clang-4.0 fastdebug assertion failure in os_linux_x86:os::verify_stack_alignment()

fi fi - if test "x$OPENJDK_TARGET_OS" = xmacosx; then -OS_CFLAGS_JVM="$OS_CFLAGS_JVM -mno-omit-leaf-frame-pointer -mstack-alignment=16" - fi - # Optional POSIX functionality needed by the JVM # # Check if clock_gettime is available and in which library. T

Re: RFR: JDK-8199331 Don't limit debug information for fastdebug JDK native libraries

Looks good! /Erik On 2018-03-08 06:19, Magnus Ihse Bursie wrote: Since long time ago, native libraries in JDK has been compiled with -g1 instead of -g, when doing a fastdebug build with gcc. (This does not apply to hotspot which is always compiled with -g.) This means that the debug

RFR: JDK-8199331 Don't limit debug information for fastdebug JDK native libraries

Since long time ago, native libraries in JDK has been compiled with -g1 instead of -g, when doing a fastdebug build with gcc. (This does not apply to hotspot which is always compiled with -g.) This means that the debug information generated is limited. The gcc manual says this about level 1

Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

t 3:42 PM, Thomas Stüfe >> wrote: >> >> Hi, >>> >>> may I please have reviews for this tiny fix: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 >>> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ >>> 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ >>> >>> Thanks and Kind Regards, Thomas >>> >>> >

Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

3:42 PM, Thomas Stüfe wrote: Hi, may I please have reviews for this tiny fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ Thanks and Kind Regards, Thomas

Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

ebrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488- >> aix-toc-overflow-in-fastdebug/webrev.00/webrev/ >> >> Thanks and Kind Regards, Thomas >> > >

Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/ > 8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ > > Thanks and Kind Regards, Thomas >

Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

boun...@openjdk.java.net] On Behalf Of Thomas Stüfe > > Sent: Donnerstag, 8. Februar 2018 15:42 > > To: ppc-aix-port-...@openjdk.java.net; build-dev > d...@openjdk.java.net> > > Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in > > fast

Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

ehalf Of *Thomas Stüfe > *Sent:* Donnerstag, 8. Februar 2018 15:42 > *To:* ppc-aix-port-...@openjdk.java.net; build-dev < > build-dev@openjdk.java.net> > *Subject:* RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so > in fastdebug build > > > > Hi, > >

Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

reviews for this tiny fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc- >> overflow-in-fastdebug/webrev.00/webrev/ >> >> Thanks and Kind Regards, Thomas >> > >

Re: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

Looks good, happy pushing without a sponsor! /Erik On 2018-02-08 06:42, Thomas Stüfe wrote: Hi, may I please have reviews for this tiny fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-overflow-in-fastdebug/webrev

RE: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build Hi, may I please have reviews for this tiny fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ Thanks and Kind

RE: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

t; build-dev d...@openjdk.java.net> > Subject: RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in > fastdebug build > > Hi, > > may I please have reviews for this tiny fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 > webrev: http://cr.ope

RFR [xxs, aix]: JDK-8196488: [aix] TOC overflow for libjvm.so in fastdebug build

Hi, may I please have reviews for this tiny fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8196488 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8196488-aix-toc-overflow-in-fastdebug/webrev.00/webrev/ Thanks and Kind Regards, Thomas

Re: RFR: JDK-8157574: Mac fastdebug bundles have wrong directory layout

Looks okay to me. Mandy > On May 23, 2016, at 7:00 AM, Erik Joelsson wrote: > > Hello, > > In JDK-8136777 I introduced the new bundle targets which creates .tar.gz > bundles of all the images. The naming and layout of these bundles were based > on how Oracle has created such bundles internal

RFR: JDK-8157574: Mac fastdebug bundles have wrong directory layout

Hello, In JDK-8136777 I introduced the new bundle targets which creates .tar.gz bundles of all the images. The naming and layout of these bundles were based on how Oracle has created such bundles internally before. Except in one case, where I missed: Macosx debug. As I see it, there is no re

Re: Is there any valid reason that a debug or fastdebug build should define PRODUCT and not ASSERT during compiles?

Hi Magnus, On 1/14/16 6:06 AM, Magnus Ihse Bursie wrote: On 2016-01-08 23:07, Derek White wrote: [This is likely a bug, but thought I'd ask it as a question first]. I'm new to jdk builds on windows, and have spent way more time than I'd like to admit on figuring out why my f

Re: Is there any valid reason that a debug or fastdebug build should define PRODUCT and not ASSERT during compiles?

On 2016-01-08 23:07, Derek White wrote: [This is likely a bug, but thought I'd ask it as a question first]. I'm new to jdk builds on windows, and have spent way more time than I'd like to admit on figuring out why my fastdebug builds did not have asserts turned on. The TL;DR;

Is there any valid reason that a debug or fastdebug build should define PRODUCT and not ASSERT during compiles?

[This is likely a bug, but thought I'd ask it as a question first]. I'm new to jdk builds on windows, and have spent way more time than I'd like to admit on figuring out why my fastdebug builds did not have asserts turned on. The TL;DR; answer is that anyone can build this wa

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

On 2015-12-17 22:32, David Holmes wrote: On 17/12/2015 7:24 PM, Erik Joelsson wrote: On 2015-12-17 09:08, David Holmes wrote: On 17/12/2015 5:54 PM, Erik Joelsson wrote: On 2015-12-17 01:40, David Holmes wrote: On 17/12/2015 7:35 AM, Erik Joelsson wrote: One more thing, where should this f

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

linux makefiles, where setting DEBUG_BINARIES did indeed enable the -g flag, but also, as a side effect, turned fastdebug builds into slowdebug builds. This was not something that we could possibly forsee. That was my understanding too - that this was simply a side-effect on hotspot, hence my sug

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

On 18/12/2015 1:58 AM, Daniel D. Daugherty wrote: DEBUG_BINARIES is one of those "hidden" HotSpot big hammers that only affects Linux (IIRC). Basically, many years ago someone got tired of trying to figure out how to get completely debuggable HotSpot build on Linux and this big hammer was dropped

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

On 17/12/2015 7:24 PM, Erik Joelsson wrote: On 2015-12-17 09:08, David Holmes wrote: On 17/12/2015 5:54 PM, Erik Joelsson wrote: On 2015-12-17 01:40, David Holmes wrote: On 17/12/2015 7:35 AM, Erik Joelsson wrote: One more thing, where should this fix be pushed? Do you need it urgently in h

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

did indeed enable the -g flag, but also, as a side effect, turned fastdebug builds into slowdebug builds. This was not something that we could possibly forsee. That was my understanding too - that this was simply a side-effect on hotspot, hence my suggestion to rename the variable. But Erik then s

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

DEBUG_BINARIES is one of those "hidden" HotSpot big hammers that only affects Linux (IIRC). Basically, many years ago someone got tired of trying to figure out how to get completely debuggable HotSpot build on Linux and this big hammer was dropped in. I could chase down who and when, but I don't t

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

On 2015-12-17 09:08, David Holmes wrote: On 17/12/2015 5:54 PM, Erik Joelsson wrote: On 2015-12-17 01:40, David Holmes wrote: On 17/12/2015 7:35 AM, Erik Joelsson wrote: One more thing, where should this fix be pushed? Do you need it urgently in hs-rt? It is urgently needed in both the

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

lso, as a side effect, turned fastdebug builds into slowdebug builds. This was not something that we could possibly forsee. I'm tempted to say rollback the whole thing rather than hack at it. I don't think there is any compelling reason to rollback the whole change. The basic idea is soun

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

ck fix for the build issue introduced in Hotspot by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true when building Hotspot fastdebug, you essentially get a slowdebug build. For an explanation of why, see comment in bug. This behavior is of course also a bug, but not something I will a

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

> > On Wed, Dec 16, 2015 at 10:34 PM, Erik Joelsson > wrote: > >> Hello, >> >> Please review this quick fix for the build issue introduced in Hotspot by >> JDK-8036003. The short story is that if you set DEBUG_BINARIES=true when >> building Hotspot fastdebug,

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

ry is that if you set DEBUG_BINARIES=true when building Hotspot fastdebug, you essentially get a slowdebug build. For an explanation of why, see comment in bug. This behavior is of course also a bug, but not something I will address in this quick fix. What happened in JDK-8036003 was that a

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

owup with a more complete fix. /Erik Thanks, David /Erik On 2015-12-16 22:34, Erik Joelsson wrote: Hello, Please review this quick fix for the build issue introduced in Hotspot by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true when building Hotspot fastdebug, you essentia

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

you set DEBUG_BINARIES=true when > building Hotspot fastdebug, you essentially get a slowdebug build. For an > explanation of why, see comment in bug. This behavior is of course also a > bug, but not something I will address in this quick fix. > > What happened in JDK-8036003 was tha

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

set DEBUG_BINARIES=true when building Hotspot fastdebug, you essentially get a slowdebug build. For an explanation of why, see comment in bug. This behavior is of course also a bug, but not something I will address in this quick fix. What happened in JDK-8036003 was that a new configure API for

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

? Thanks, David /Erik On 2015-12-16 22:34, Erik Joelsson wrote: Hello, Please review this quick fix for the build issue introduced in Hotspot by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true when building Hotspot fastdebug, you essentially get a slowdebug build. For an

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

On 2015-12-16 22:34, Erik Joelsson wrote: Hello, Please review this quick fix for the build issue introduced in Hotspot by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true when building Hotspot fastdebug, you essentially get a slowdebug build. For an explanation of why

Re: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

building Hotspot fastdebug, you essentially get a slowdebug build. For an explanation of why, see comment in bug. This behavior is of course also a bug, but not something I will address in this quick fix. What happened in JDK-8036003 was that a new configure API for controlling debug symbols was

RFR: JDK-8145564: 8036003: startup regression on linux fastdebug builds

Hello, Please review this quick fix for the build issue introduced in Hotspot by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true when building Hotspot fastdebug, you essentially get a slowdebug build. For an explanation of why, see comment in bug. This behavior is of

Re: Why does a fastdebug build compile with -O3 *and* -O0?

Hi Mikael, Adding in build-dev for input. On Tue, 2015-04-28 at 10:55 +0200, Mikael Gerdin wrote: > Severin, > > On 2015-04-27 16:33, Severin Gehwolf wrote: > > Hi, > > > > I've noticed that a fastdebug build of recent hs-rt compiles objects > > with -O3

Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams

Your call. Dan On 8/20/14 11:05 AM, Christian Tornqvist wrote: I talked to Staffan Friberg (perf tech lead) about enabling this in a release builds and this is his opinion: "For /homeparams I think enable it now in fastdebug, let's use it for a while and understand home much of a

RE: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams

I talked to Staffan Friberg (perf tech lead) about enabling this in a release builds and this is his opinion: "For /homeparams I think enable it now in fastdebug, let's use it for a while and understand home much of a benefit it is for debugging. If it is a huge help let's

Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams

On 8/20/14 9:48 AM, Christian Tornqvist wrote: indicate that we shouldn't need this change in our debug/fastdebug builds. However, you looked at the generated prologue code before and after turning on this option right? Our fastdebug builds are compiled with /O2 which doesn't

RE: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams

> indicate that we shouldn't need this change in our debug/fastdebug builds. However, you looked at the generated prologue code before and after turning on this option right? Our fastdebug builds are compiled with /O2 which doesn't spill the parameters onto the stack, our debug bui

Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams

On 8/20/14 8:49 AM, Christian Tornqvist wrote: Do we have any idea how much of a change? Do we care? I'm presuming the increased debuggability is worth it. It adds 0-4 additional stack movs in function prologue code which should have a very low impact, it's only on debug/fastdebug b

RE: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams

> Do we have any idea how much of a change? Do we care? I'm presuming the increased debuggability is worth it. It adds 0-4 additional stack movs in function prologue code which should have a very low impact, it's only on debug/fastdebug builds. > The above block will also a

RE: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams

Adding build-dev as well -Original Message- From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On Behalf Of Christian Tornqvist Sent: Tuesday, August 19, 2014 7:39 PM To: hotspot-...@openjdk.java.net Subject: RFR(S): 8027480 - Build Windows x64 fastdebug builds using

Re: RFR: 8047952 : (s) Remove FORTIFY_SOURCE from fastdebug and slowdebug builds

Hiya Mike , On 09/08/14 01:23, Mike Duigou wrote: Hello all; A previous version of this changeset was focused on disabling FORTIFY_SOURCE only for specific files with optimization disabled. This version entirely disables FORTIFY_SOURCE for all portions of the build. After additional problems

Re: RFR: 8047952 : (s) Remove FORTIFY_SOURCE from fastdebug and slowdebug builds

On Aug 11, 2014, at 7:09 PM, Mike Duigou wrote: > > You are correct. The release and fastdebug need to be combined into one > clause. I will fix this. Bash 4.0 doesn't appear to complain about the > fallthrough but better to be compliant. Other than that, looks good.

Re: RFR: 8047952 : (s) Remove FORTIFY_SOURCE from fastdebug and slowdebug builds

You are correct. The release and fastdebug need to be combined into one clause. I will fix this. Bash 4.0 doesn't appear to complain about the fallthrough but better to be compliant. Mike On Aug 11 2014, at 15:05 , Kim Barrett wrote: > On Aug 8, 2014, at 8:23 PM, Mike Duigo

Re: RFR: 8047952 : (s) Remove FORTIFY_SOURCE from fastdebug and slowdebug builds

abled selectively for specific platforms. > > webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047952/1/webrev/ > jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047952 > > Mike In common/autoconf/flags.m4: 339 if test "x$TOOLCHAIN_TYPE" = xgcc; then 340 case $DEBU

Re: RFR: 8047952 : (s) Remove FORTIFY_SOURCE from fastdebug and slowdebug builds

On 9/08/2014 10:23 AM, Mike Duigou wrote: Hello all; A previous version of this changeset was focused on disabling FORTIFY_SOURCE only for specific files with optimization disabled. This version entirely disables FORTIFY_SOURCE for all portions of the build. After additional problems; incompa

RFR: 8047952 : (s) Remove FORTIFY_SOURCE from fastdebug and slowdebug builds

Hello all; A previous version of this changeset was focused on disabling FORTIFY_SOURCE only for specific files with optimization disabled. This version entirely disables FORTIFY_SOURCE for all portions of the build. After additional problems; incompatibility of FORTIFY_SOURCE with -O0, lack of

Re: RFR: JDK-8035904: Solaris fastdebug builds are failing

Hi Erik: JDK-8034199 unfortunately didn't work with a bunch of internal Solaris installations. It seems common for Solaris 10 to not have an updated bash version and the =~ construct used in that patch requires bash 3.x or higher. Here is a rewrite of that part using grep. Looks good to m

RFR: JDK-8035904: Solaris fastdebug builds are failing

JDK-8034199 unfortunately didn't work with a bunch of internal Solaris installations. It seems common for Solaris 10 to not have an updated bash version and the =~ construct used in that patch requires bash 3.x or higher. Here is a rewrite of that part using grep. Bug: https://bugs.openjdk.ja

Re: Solaris fastdebug build: gobjcopy?

On 22/10/2013 9:31 AM, Weijun Wang wrote: On 10/21/13 9:18 PM, Magnus Ihse Bursie wrote: 21 okt 2013 kl. 14:28 skrev Weijun Wang : This is a full build, but I run configure on one machine and make from another. That is not a supported use case. Configure checks the local machine and prepares

Re: Solaris fastdebug build: gobjcopy?

On 10/21/13 9:18 PM, Magnus Ihse Bursie wrote: 21 okt 2013 kl. 14:28 skrev Weijun Wang : This is a full build, but I run configure on one machine and make from another. That is not a supported use case. Configure checks the local machine and prepares the build. Yes I know. On the other

Re: Solaris fastdebug build: gobjcopy?

Running configure on a machine with gobjcopy and then running the build on a machine without gobjcopy would explain the failure mode that you're seeing. You need to file a bug with the build-infra folks. The old build system wouldn't have had this problem because there was no configure step. I'm n

Re: Solaris fastdebug build: gobjcopy?

21 okt 2013 kl. 14:28 skrev Weijun Wang : > This is a full build, but I run configure on one machine and make from > another. That is not a supported use case. Configure checks the local machine and prepares the build. /Magnus > Doing both on the same machine without gobjcopy runs fine. > >

Re: Solaris fastdebug build: gobjcopy?

This is a full build, but I run configure on one machine and make from another. Doing both on the same machine without gobjcopy runs fine. Thanks Max On 10/21/13 7:38 PM, David Holmes wrote: If gobjcopy is installed somewhere then ALT_OBJCOPY can be set to point to it. Was this part of a full

Re: Solaris fastdebug build: gobjcopy?

Hi Max, On 21/10/2013 7:00 PM, Weijun Wang wrote: Hi All I'm trying --enable-debug on a Solaris and see this failure ## Starting hotspot INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/sfw/bin/gobjcopy INFO: no objcopy cmd found so cannot create .debuginfo files. INFO: ENABLE_FULL_DEB

Solaris fastdebug build: gobjcopy?

Hi All I'm trying --enable-debug on a Solaris and see this failure ## Starting hotspot INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/sfw/bin/gobjcopy INFO: no objcopy cmd found so cannot create .debuginfo files. INFO: ENABLE_FULL_DEBUG_SYMBOLS=0 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO:

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

Pushed to jdk8/tl/jdk. I recommend this be backported to jdk7u.

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

On Mon, Mar 4, 2013 at 3:02 AM, Florian Weimer wrote: > On 02/22/2013 11:03 PM, Martin Buchholz wrote: > > I've finally figured out why fastdebug jdk occasionally gives >> InternalError >> in the zip code. >> > > In the distant past, I also saw this with pr

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

On 02/22/2013 11:03 PM, Martin Buchholz wrote: I've finally figured out why fastdebug jdk occasionally gives InternalError in the zip code. In the distant past, I also saw this with product builds. Triggering conditions involved a JNI DSO calling dlopen(RTLD_GLOBAL) on another DSO

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

On Mar 1, 2013, at 6:44 AM, Alan Bateman wrote: >> It's hard to find something more standard than stddef.h. >> > It's hard to find something as non-standard as Windows. My point was we just > need to double check that this builds okay on Windows, which is does. The only issue I have seen with

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

On 28/02/2013 16:11, Martin Buchholz wrote: On Thu, Feb 28, 2013 at 6:03 AM, Alan Bateman > wrote: The update to make/java/zip/Makefile looks good to me, we should have done it a long time ago. I assume you are pushing ahead on this because you want

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

On Thu, Feb 28, 2013 at 6:03 AM, Alan Bateman wrote: > The update to make/java/zip/Makefile looks good to me, we should have > done it a long time ago. I assume you are pushing ahead on this because you > want to push it to jdk7u-dev (as it's not interesting to jdk8 now because > of the new buil

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

On 27/02/2013 23:16, Martin Buchholz wrote: I have another iteration of this change http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ that adds exciting new exception detail message for the InternalError I was scrat

  1   2   >