[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling
From:       Coleen Phillimore <coleen.phillimore () oracle ! com>
Date:       2015-03-20 20:39:11
Message-ID: 550C856F.9070208 () oracle ! com
[Download RAW message or body]


On 3/20/15, 4:27 AM, Severin Gehwolf wrote:
> 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.

I'm compiling for linux 64 bit debug on ubuntu.

philli% gcc --version
gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2

>
> 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.

I don't know how to consistently catch these gcc errors so they don't 
keep falling through the cracks! :(

Yes, please use hs-rt for this.  I think we are more interested at the 
moment.

thanks!
Coleen
>
> 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)
>>>>
>>>>
>>>
>
>

[prev in list] [next in list] [prev in thread] [next in thread]