[patch] Fix oddity in personality routine

Tue Nov 17 14:56:00 GMT 2009

Jack Howarth wrote:
> On Tue, Nov 17, 2009 at 10:58:00AM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Mon, Nov 16, 2009 at 07:08:49PM +0000, Andrew Haley wrote:
>>>> There's another unwinder? Gosh.
>>>>>>>> Set a bp on '_Jv_Throw' and step through. You'll need to compile libgcc
>>>> with -O0 or you'll go insane. The unwinder is quite complex, and it takes
>>>> a fair while to understand it.
>>> I have added an unwinder_walk.txt attachment to PR41991. It is a walk
>>> from the _Jv_Throw breakpoint for ecj1 compiling the testme.java test code
>>> with a libgcc compiled with -O0 installed. This is with current gcc trunk
>>> using the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3
>>> compiled on x86_64-apple-darwin9.8.0 to make sure that the FSF libgcc is
>>> used. Hopefully a fix can be found in the libjava code that calls the
>>> unwinder as fixing this within the unwinder won't help us with darwin10
>>> or later.
>> There's probably nothing wrong with the libjava code that calls the
>> unwinder: after all, it works everywhere else. I'm betting this is
>> bad unwind info.
>>>> Anyway, at least this is a start. It tells us that the stack is
>> walked but no landing pad is found. We don't know why.

> In the unwinder walk, are there any particular places where I could
> get additional debug information in gdb that would be helpful to diagnose this
> issue?

Sure. The trace you provided is very incomplete, and in particular
I can't see any stepping into _Unwind_RaiseException.
The main loop looks like this:
 while (1)
 {
 _Unwind_FrameState fs;
 /* Set up fs to describe the FDE for the caller of cur_context. The
	 first time through the loop, that means __cxa_throw. */
 code = uw_frame_state_for (&cur_context, &fs);
 if (code == _URC_END_OF_STACK)
	/* Hit end of stack with no handler found. */
	return _URC_END_OF_STACK;
 if (code != _URC_NO_REASON)
	/* Some error encountered. Usually the unwinder doesn't
	 diagnose these and merely crashes. */
	return _URC_FATAL_PHASE1_ERROR;
 /* Unwind successful. Run the personality routine, if any. */
 if (fs.personality)
	{
	 code = (*fs.personality) (1, _UA_SEARCH_PHASE, exc->exception_class,
				 exc, &cur_context);
	 if (code == _URC_HANDLER_FOUND)
	 break;
	 else if (code != _URC_CONTINUE_UNWIND)
	 return _URC_FATAL_PHASE1_ERROR;
	}
 /* Update cur_context to describe the same frame as fs. */
 uw_update_context (&cur_context, &fs);
 }
So, for each stack frame, we read the unwinder data and then call the
appropriate personality routine (in this case, in libgcj.)
cur_context.ra is the program counter for the current stack frame.
So,
(gdb) x cur_context.ra
0x7ffff659ca7f <_ZN4java3net14URLClassLoader9findClassEJPNS_4lang5ClassEPNS2_6StringE+255>:	0x41c58949
tells you which frame is being inspected. So, you can see where the
exception handler should be, and you can step into the personality
routine to see why it's not recognized.
> Also, what do you make of the fact that the generated libjava Makefile
> uses ecjx_LDFLAGS before it is actually assigned...
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c10

That's probably not right.
> Could this sort of problem be caused by a build issue from improper Makefiles?

Sorry, I hate to speculate. I simply don't know.
> Andreas suppressed the crash on his machine using the change in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c3 but that is insufficient
> to fix it on either my MacBook Pro or MacPro under either darwin9 or darwin10
> (which is odd).

It may be a completely different problem. He's seeing a SEGV, you're not.
Andrew.