Re: [patch] Fix oddity in personality routine
Andrew Haley <[email protected]>
| Newsgroups | gmane.comp.gcc.java.devel |
|---|---|
| Message-ID | <[email protected]> |
Jack Howarth wrote: > 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? 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.