RFR(s): 8065895: Synchronous signals during error reporting may terminate or hang VM process

[Thomas Stüfe]

Hi all,

lets not get this patch bogged down on ARM opcode discussions.

For me, it is just a question of style and which one would be most
acceptable to the OpenJDK.

As I see it, here are my options:

1  leave the code as it is and whoever does ARM porting at Oracle will
provide the SIGILL opcodes inside debug.cpp
2  like (1), but provide a fallback for CPUs where we do not know the
SIGILL opcodes right now, by doing a raise(SIGILL). This would work but
make the test a tiny bit less valuable on those platforms.

3  Move the CPU-dependend parts (the big #ifdef) away from debug.cpp into
debug_<cpu>.cpp. Would mean a bit code duplication because for 3 out of 5
cpus the SIGILL-generating opcode is 0. This basically would be the same as
my second webrev (
http://cr.openjdk.java.net/~stuefe/webrevs/8065895/webrev.01/)
4  like (3), but with additional introduction of a debug_<cpu>.hpp, and
adding a "ZERO_WILL_GENERATE_SIGILL" or somesuch macro to provide a common
fallback for cpus where 0 generates SIGILL.

I am leaning toward (2) or (3) but I am okay with any of the four.

Kind Regards,

Thomas Stuefe








On Thu, Nov 27, 2014 at 12:04 PM, Andrew Haley <aph at redhat.com> wrote:

> On 11/27/2014 11:00 AM, David Holmes wrote:
> > On 27/11/2014 8:55 PM, Andrew Haley wrote:
> >> On 11/27/2014 10:38 AM, Thomas Stüfe wrote:
> >>> Hi Andrew, thank you! Does endianess matter ?
> >>
> >> Yes.  I'd do it symbolically rather than mess with endian defines:
> >>
> >> #ifdef AARCH64
> >>    unsigned insn;
> >>    asm("b 1f; 0: dcps1; 1: ldr %0, 0b" : "=r"(insn));
> >> #endif
> >
> > Does that work for ARMv7?
>
> Sorry, I don't know what a good choice there would be.  And I must
> warn you: DCPS1 isn't necessarily guaranteed to do this forever, but
> it works on the kernels I've tried.
>
> Andrew.
>
>
>