Re: [patch] Fix oddity in personality routine

[Andrew Haley <aph at redhat dot com>]

Jack Howarth wrote:
> On Sat, Nov 28, 2009 at 10:43:26AM +0000, Andrew Haley wrote:
>> Jack Howarth wrote:
>>> On Fri, Nov 27, 2009 at 10:40:17AM +0000, Andrew Haley wrote:
>>>> borlum wrote:
>>>>> Jack Howarth-3 wrote:
>>>>>> On Tue, Nov 17, 2009 at 05:13:31PM +0000, Andrew Haley wrote:
>>>>>>> Sometimes it doesn't work, so you have to be inventive.  Try
>>>>>>> setting a breakpoint on Unwind_RaiseException, or step a single
>>>>>>> instruction at a time when you get to a call.
>>>>>>>
>>>>>>>> I assume that gcc trunk's
>>>>>>>> debug code is still compatible with Apple's gdb. If not, I do have
>>>>>>>> a build of gdb 7.0 on Intel darwin that I can use instead. Thanks
>>>>>>>> in advance for any hints on this issue.
>>>>>>>>               Jack
>>>>>>>> ps I do notice that gdb can't find the object files from
>>>>>>> /sw/src/fink.build/gcc45-4.4.999-20091116/darwin_objdir/x86_64-apple-darwin9.8.0/libjava/.libs/libgcj.lax
>>>>>>> so it might have problems with debugging within libgcj. If I recall
>>>>>>> correctly this .lax issue is known...
>>>>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html
>>>>>>> Ouch.  That will cause gdb breakage, for sure.
>>>>>> Andrew,
>>>>>>    Re-reading Peter's comments in
>>>>>> http://gcc.gnu.org/ml/gcc/2008-10/msg00083.html, I think I
>>>>>> may be able to work around the lax issue with the proper setting of
>>>>>> LD_LIBRARY to point to 
>>>>>> the shared library in the build directory. I'll see if I can puzzle that
>>>>>> one out.
>>>>>>                  Jack
>>>>>>> Andrew.
>>>>> Hey Andrew,
>>>>>
>>>>> Did you ever solve the problem? I'm having the same rather frustrating
>>>>> error.
>>>> Not me, no.  I don't have a Darwin system.
>>>     Now that we have a set of patches to fix the breakage in current gcc
>>> trunk to dsymutil, I have uploaded a much more complete walk under x86_64-apple-darwin10.
>>> I haven't managed to walk into _Unwind_Exception() yet but I do see that the 
>>> crash occurs on continuing from the 39th instance of the _Unwind_Exception() breakpoint.
>> That's probably just the end of the stack.  If you do a stack trace
>> in gdb you'll probably find it's something like 39 deep.
>>
>>> Is there some way I can get the unwinder data from inside of libgcj itself before
>>> the call to _Unwind_Exception()? If the bad unwind information is being generated in
>>> libjava wouldn't it be just as easy to see that from outside of libgcc (before the call
>>> to _Unwind_Exception()?
>> You mean decoding the unwinder data by hand?  It's not impossible, but
>> it'd be a hell of a job.
>>
>    I managed to get a build of libgcc at -O0 under darwin9 that I used to walk through
> the FSF gcc unwinder. The walk is at...
> 
> http://gcc.gnu.org/bugzilla/attachment.cgi?id=19174
> 
> and the list of the frames is at...
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991#c26
> 
> Does this clarify the problem at all on intel darwin? Let me know if there
> is any other particular debug information I can provide.

It stops when unwinding java.lang.ClassLoader.loadClass(java.lang.String, boolean),
either because the unwinder data is buggy (probably) or because the unwinder
itself is buggy.

It's hard to be exactly clear what's going wrong, but it may be that the place
it fails is at the point where the program calls libgcj.

Andrew.