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 8205445: Add RSASSA-PSS Signature support to SunMSCAPI

> On Jun 23, 2018, at 8:35 AM, Valerie Peng wrote: > > On 6/22/2018 3:23 PM, Weijun Wang wrote: >>> On Jun 23, 2018, at 2:30 AM, Valerie Peng wrote: >>> >>> Max, >>> >>> Good catch on the SunRsaSign provider bug. >>> >>> Looking at the changes, I think we may have to fine-grain the check o

Re: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI

On 6/22/2018 3:23 PM, Weijun Wang wrote: On Jun 23, 2018, at 2:30 AM, Valerie Peng wrote: Max, Good catch on the SunRsaSign provider bug. Looking at the changes, I think we may have to fine-grain the check on the ensureInit() call, i.e. use ensureInit(boolean sign) instead of ensureInit(

Re: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI

> On Jun 23, 2018, at 2:30 AM, Valerie Peng wrote: > > Max, > > Good catch on the SunRsaSign provider bug. > > Looking at the changes, I think we may have to fine-grain the check on the > ensureInit() call, i.e. > > use ensureInit(boolean sign) instead of ensureInit(), as the current metho

Re: RFR(M): 8205207: Port Graal unit tests under jtreg

Fixed and regenerated webrev at the same location: http://cr.openjdk.java.net/~epavlova//8205207/webrev.01/index.html Erik, thanks again for your detailed reviews! -katya On 6/22/18 2:38 PM, Erik Joelsson wrote: Hello Katya, This looks much better, thanks! A few suggestions still: Main.gmk

Re: RFR(M): 8205207: Port Graal unit tests under jtreg

On 6/22/18 2:29 PM, Doug Simon wrote: On 22 Jun 2018, at 23:16, Ekaterina Pavlova wrote: Erik, Doug, thank you a lot for your reviews and advises. I fixed everything what Erik has pointed out, please see my answers inlined. As about moving more staff in 'updategraalinopenjdk' can we consid

Re: RFR(M): 8205207: Port Graal unit tests under jtreg

> On 22 Jun 2018, at 23:29, Doug Simon wrote: > > > >> On 22 Jun 2018, at 23:16, Ekaterina Pavlova >> wrote: >> >> Erik, Doug, >> >> thank you a lot for your reviews and advises. >> I fixed everything what Erik has pointed out, please see my answers inlined. >> As about moving more staff

Re: RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC

Hello Jini, In general this looks pretty good, but it's also breaking some new ground as it's adding generation of native source in the java gensrc step. Mixing native code with the java code that the genrcs targets and gensrc output directories are meant for seems ok for now, but may cause t

Re: RFR(M): 8205207: Port Graal unit tests under jtreg

Hello Katya, This looks much better, thanks! A few suggestions still: Main.gmk: instead of repeating the assignment in both if and else block: ifeq ($(INCLUDE_GRAAL), true)   JVM_TEST_IMAGE_TARGETS += test-image-hotspot-jtreg-graal endif I think it's fine to do that without the ?= because an

Re: RFR(M): 8205207: Port Graal unit tests under jtreg

> On 22 Jun 2018, at 23:16, Ekaterina Pavlova > wrote: > > Erik, Doug, > > thank you a lot for your reviews and advises. > I fixed everything what Erik has pointed out, please see my answers inlined. > As about moving more staff in 'updategraalinopenjdk' can we consider this as > next step?

Re: RFR(M): 8205207: Port Graal unit tests under jtreg

Erik, Doug, thank you a lot for your reviews and advises. I fixed everything what Erik has pointed out, please see my answers inlined. As about moving more staff in 'updategraalinopenjdk' can we consider this as next step? I am not quite familiar with 'updategraalinopenjdk' and didn't contribute

Re: RFR 8205445: Add RSASSA-PSS Signature support to SunMSCAPI

Max, Good catch on the SunRsaSign provider bug. Looking at the changes, I think we may have to fine-grain the check on the ensureInit() call, i.e. use ensureInit(boolean sign) instead of ensureInit(), as the current method only ensures that at least one of the privKey, pubKey or fallbackSig

RFR: JDK-8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC

Hi all, [Including build-dev also since this includes build related changes]. Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8189429 (SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC) Webrev: http://cr.openjdk.java.net/~jgeorge/8189429/webrev.04/ This is the

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 8205445: Add RSASSA-PSS Signature support to SunMSCAPI

Looks fine to me. Thanks, Xuelei On 6/21/2018 10:39 PM, Weijun Wang wrote: Webrev updated at http://cr.openjdk.java.net/~weijun/8205445/webrev.01 I think I found a bug in SunRsaSign of the RSASSA-PSS signature. Fixed and added a test. BTW, I commented out the debug code in security.cpp.

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: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

Hi Severin! On 06/22/2018 01:19 PM, Severin Gehwolf wrote: >> Now, before I create the bug report, do you happen to know which changeset >> introduced the regression? We usually include that in the bug report. > > http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855 > >> And I also need to know w

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

On Fri, 2018-06-22 at 12:53 +0200, John Paul Adrian Glaubitz wrote: > Hi Fridrich! > > On 06/21/2018 02:34 PM, Fridrich Strba wrote: > > Yes, I have tested this consolidated version and it builds just fine for me. > > I have just verified that the problem exists on Debian unstable as well when >

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

Hi Fridrich! On 06/21/2018 02:34 PM, Fridrich Strba wrote: > Yes, I have tested this consolidated version and it builds just fine for me. I have just verified that the problem exists on Debian unstable as well when using the system headers for libjpeg and the other libraries. I can also confirm th