This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Divide_1 testsuite fail due to a problem in the unwinding code
- From: Andrew Haley <aph at redhat dot com>
- To: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 27 Jan 2012 17:01:59 +0000
- Subject: Re: Divide_1 testsuite fail due to a problem in the unwinding code
- References: <20120127164616.GA8167@bart>
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.