> Mmmh. But actually it is the stack frame of _divdi3 and not the signal
> frame which gets the wrong cfa assigned from here. Not sure though,
> perhaps it's time to draw a picture ;)
The restored context inherits the signal flag set in the frame description and
its CFA points to within _divdi3.
On 01/27/2012 06:16 PM, Andrew Haley wrote:
> On 01/27/2012 05:14 PM, Dave Korn wrote:
>> On 27/01/2012 17:01, Andrew Haley wrote:
>>> On 01/27/2012 04:46 PM, Andreas Krebbel wrote:
>>
Starting with this IRA patch:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html
__divdi3 does
On Fri, Jan 27, 2012 at 06:08:23PM +0100, Eric Botcazou wrote:
> > To my understanding this can only happen if there is control flow from
> > a leaf function which in turn should only occur with signals. Perhaps
> > we could modify the CFA "a bit" for the frame where the signal
> > occurred? Ther
[answering to self...]
> Why does this "hack" not work? It was precisely devised for this purpose.
Probably because you don't set fs->signal_frame in the fallback routine:
/* SIGILL, SIGFPE and SIGTRAP are delivered with psw_addr
after the faulting instruction rather than before it.
On 01/27/2012 05:18 PM, Dave Korn wrote:
> On 27/01/2012 17:16, Andrew Haley wrote:
>> On 01/27/2012 05:14 PM, Dave Korn wrote:
>>> On 27/01/2012 17:01, Andrew Haley wrote:
On 01/27/2012 04:46 PM, Andreas Krebbel wrote:
> Starting with this IRA patch:
> http://gcc.gnu.org/ml/gcc-patche
On 27/01/2012 17:16, Andrew Haley wrote:
> On 01/27/2012 05:14 PM, Dave Korn wrote:
>> On 27/01/2012 17:01, Andrew Haley wrote:
>>> On 01/27/2012 04:46 PM, Andreas Krebbel wrote:
Starting with this IRA patch:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html
__divdi3 does *not*
On 01/27/2012 05:14 PM, Dave Korn wrote:
> On 27/01/2012 17:01, Andrew Haley wrote:
>> On 01/27/2012 04:46 PM, Andreas Krebbel wrote:
>
>>> Starting with this IRA patch:
>>> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html
>>> __divdi3 does *not* need a stack frame at all.
>>>
>>> So the CF
On 27/01/2012 17:01, Andrew Haley wrote:
> On 01/27/2012 04:46 PM, Andreas Krebbel wrote:
>> Starting with this IRA patch:
>> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html
>> __divdi3 does *not* need a stack frame at all.
>>
>> So the CFAs of __divdi3 and probe_1 are the same!
>
> I'm c
> To my understanding this can only happen if there is control flow from
> a leaf function which in turn should only occur with signals. Perhaps
> we could modify the CFA "a bit" for the frame where the signal
> occurred? There is already a hack in uw_identify_context which does
> this for the si
On 27/01/2012 16:58, Dave Korn wrote:
> On 27/01/2012 16:46, Andreas Krebbel wrote:
>> So the CFAs of __divdi3 and probe_1 are the same!
>>
>> This triggers the assertion in _Unwind_RaiseException_Phase2 which
>> assumes that it is about to pass the frame with the handler without
>> actually findi
On 01/27/2012 04:46 PM, Andreas Krebbel wrote:
> while debugging the java failure Divide_1 on s390 I stumbled over
> some weird behaviour in the unwinding code.
>
> In the testcase a divide by zero is triggered intentionally. So that
> the java sigfpe handler is invoked in __divdi3:
>
> Divide_1::p
On 27/01/2012 16:46, Andreas Krebbel wrote:
> Divide_1::probe_1() -> __divdi3
>|SIGFPE
>V
> catch_fpe -> _Jv_Throw
>
> After doing the instruction parsing in order to figure out whether
> it's actually the INT_MIN/-
Hi,
while debugging the java failure Divide_1 on s390 I stumbled over
some weird behaviour in the unwinding code.
In the testcase a divide by zero is triggered intentionally. So that
the java sigfpe handler is invoked in __divdi3:
Divide_1::probe_1() -> __divdi3
|SIGFP
13 matches
Mail list logo
