[patch] Fix oddity in personality routine

[Jack Howarth]

On Sun, Nov 29, 2009 at 06:00:57PM +0000, Andrew Haley wrote:
> 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.

  Would it help if I just used a breakpoint on uw_frame_state_for() and provided all
of the unwinding info that is being processed? Might that clarify if the unwinder
data is buggy?
                                 Jack
> 
> 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.