Re: [patch] Fix oddity in personality routine

On Tue, Nov 17, 2009 at 02:54:53PM +0000, Andrew Haley wrote:
> 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.
> 
Andrew,
   One question about the absence of stepping into _Unwind_RaiseException.
Am I doing the walk incorrectly? The steps I used were...

1) gdb /sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin9.8.0/4.5.0/ecj1
2) (gdb) break _Jv_Throw
3) r testme.java -fbootclasspath=./:/sw/lib/gcc4.5/share/java/libgcj-4.5.0.jar -fsource=1.5 -ftarget=1.5 -fzip-dependency /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccnFt6vF.zip -fzip-target /var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccrNgp0M.jar
4) (gdb) s
5) repeatedly hit return to continue stepping through the code

Is there something wrong with that approach which would have kept me
from walking into Unwind_RaiseException? 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



> 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.