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.
