RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling

[Severin Gehwolf]

On Thu, 2015-03-19 at 14:57 -0400, Coleen Phillimore wrote:
> Yes, this patch looks like what I'm testing with.  I also had to make 
> this change to get it to compile on linux x64.
> 
> --- a/src/cpu/zero/vm/frame_zero.cpp
> +++ b/src/cpu/zero/vm/frame_zero.cpp
> @@ -213,7 +213,7 @@
>       valuebuf[buflen - 1] = '\0';
> 
>       // Print the result
> -    st->print_cr(" " PTR_FORMAT ": %-21s = %s", addr, fieldbuf, valuebuf);
> +    st->print_cr(" " PTR_FORMAT ": %-21s = %s", p2i(addr), fieldbuf, 
> valuebuf);
>     }
>   }

Interesting. I haven't seen this before. What's the exact environment
you are compiling on? Which GCC? slowdebug, fastdebug or release type
build? FWIW, Fedora 21 on x86_64 Zero slowdebug build didn't need this.
It compiled fine here.

There ought to be a way for those things to not slip through the
cracks... I already have this [1] and [2]. Those are using hs-comp trees
currently. I'll probably switch them over to use hs-rt instead.

Thanks again, Coleen!

Cheers,
Severin

[1] http://builder.classpath.org/jenkins/job/OpenJDK9_hscomp_Zero/
[2] http://builder.classpath.org/jenkins/job/OpenJDK8_jdk8u_Zero/

> On 3/19/15, 10:31 AM, Severin Gehwolf wrote:
> > On Thu, 2015-03-19 at 11:28 +0000, Andrew Dinn wrote:
> >> On 19/03/15 09:35, Thomas Stüfe wrote:
> >>> this may be the case. I do not know the zero port very good.
> >>>
> >>> SefeFetch handling needs support from both signal handler and access
> >>> routines to ucontext_t (ucontext_set_pc(), ucontext_get_pc()). Both is
> >>> missing.
> >>>
> >>> In theory it could be added, because doing so requires no assembly of any
> >>> sorts. But it looks like the zero port avoids any technique which requires
> >>> fiddling around with the ucontext_t in the signal handler to jump to a
> >>> continuation point. This looks intentional and I do not want to introduce
> >>> any code which breaks the intention of zero port.
> >>>
> >>> Of course, the other way would be just to disable the test for zero.
> >>>
> >>> What would be the right way?
> > Thomas, I think the way to go is to skip both, the test and the new
> > error handler feature for Zero. Since it is C++ interpreter only, it's
> > OK to not have this extra info in hs_err.
> >
> > Shark, on the other hand, is likely different but I don't know much
> > about it.
> >
> >> Coleen, thanks very much for checking to see if this fix causes an issue
> >> for zero.
> > +1, very much appreciated!
> >
> > I see that this has already been pushed[1]. I'll follow up with a fix
> > for Zero shortly (current w-i-p patch attached).
> >
> > Cheers,
> > Severin
> >
> > [1] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/3eb61269f421
> >
> >> Thomas, I have pointed the relevant Red Hat developers at this thread.
> >> One of them should respond soon.
> >>
> >> regards,
> >>
> >>
> >> Andrew Dinn
> >> -----------
> >> Senior Principal Software Engineer
> >> Red Hat UK Ltd
> >> Registered in UK and Wales under Company Registration No. 3798903
> >> Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
> >> (USA), Michael O'Neill (Ireland)
> >>
> >>
> >
> >
>