This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
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.