[aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86

[Doerr, Martin]

Hi,

I have prepared a change to use SIGTRAP on PPC64 for stop functions etc. I'll test it and post a separate RFR at a later point of time.

Just for you upfront in case you would like to take a look:
https://bugs.openjdk.java.net/browse/JDK-8244949
http://cr.openjdk.java.net/~mdoerr/8244949_ppc64_asm_stop/webrev.00/

@lx: Btw. Please use bug id in subject line of RFR emails.

Best regards,
Martin


> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Donnerstag, 7. Mai 2020 19:48
> To: Doerr, Martin <martin.doerr at sap.com>; Derek White
> <derekw at marvell.com>; Ningsheng Jian <ningsheng.jian at arm.com>; Liu,
> Xin <xxinliu at amazon.com>; hotspot-compiler-dev at openjdk.java.net
> Cc: aarch64-port-dev at openjdk.java.net
> Subject: Re: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information
> when hitting a HaltNode for architectures other than x86
> 
> On 5/7/20 9:11 AM, Andrew Haley wrote:
> > On 5/6/20 9:45 PM, Doerr, Martin wrote:
> >> I had also thought about using a trap based implementation.
> >> Maybe it makes sense to add a feature to shared code for that.
> >> E.g. we could emit an illegal instruction (which raises SIGILL) followed by
> some kind of index into a descriptor array.
> >> PPC64 would also benefit from a more compact solution.
> >
> > Most of the stuff to handle this would be in the back end, I would
> > have thought. I'll have a look.
> 
> This attached patch does the job for Linux/AArch64. It has two
> disadvantages:
> 
> 1. It corrupts R8, rscratch1. This doesn't really matter for AArch64.
> 
> 2. If we execute stop() in the context of a signal handler triggered
>    by another trap, we'll have a double fault and the OS will kill our
>    process.
> 
> 1 is fixable by pushing rscratch1 before executing the trap. I'm not
> sure it's worth doing; I'd rather have a tiny implementation of stop()
> that we can use guilt-free in release code.
> 
> I don't think 2 is an issue because we never call out to generated
> code from a signal handler.
> 
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671