Divide_1 testsuite fail due to a problem in the unwinding code

[Andrew Haley]

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::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/-1 case or not an exception is thrown.
>
> During _Unwind_RaiseException the handler is found in probe_1 and in
> order to re-find it in phase2 the CFA! is recorded in the private_2 field
> of the exception.
>
> 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 confused.

But __divdi3 should have been compiled with enough unwinder data
that it can be found; it should not matter whether __divdi3 has
a stack frame or not.

So why doesn't __divdi3 have a CFA of its own?

Andrew.