From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2183 invoked by alias); 17 Nov 2009 17:07:55 -0000 Received: (qmail 2168 invoked by uid 22791); 17 Nov 2009 17:07:53 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from bromo.med.uc.edu (HELO bromo.med.uc.edu) (129.137.3.146) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Tue, 17 Nov 2009 17:07:01 +0000 Received: from bromo.med.uc.edu (localhost.localdomain [127.0.0.1]) by bromo.med.uc.edu (Postfix) with ESMTP id 752D1B005D; Tue, 17 Nov 2009 12:06:59 -0500 (EST) Received: (from howarth@localhost) by bromo.med.uc.edu (8.14.3/8.14.3/Submit) id nAHH6xII020559; Tue, 17 Nov 2009 12:06:59 -0500 Date: Tue, 17 Nov 2009 17:07:00 -0000 From: Jack Howarth To: Andrew Haley Cc: java@gcc.gnu.org Subject: Re: [patch] Fix oddity in personality routine Message-ID: <20091117170659.GA20342@bromo.med.uc.edu> References: <20091116151118.GA7296@bromo.med.uc.edu> <4B016CB7.7060406@redhat.com> <20091116153406.GA7828@bromo.med.uc.edu> <4B0184A2.4080408@redhat.com> <20091116180632.GA9747@bromo.med.uc.edu> <4B01A341.6000206@redhat.com> <20091117004721.GA13498@bromo.med.uc.edu> <4B0281B8.9020406@redhat.com> <20091117140504.GA17989@bromo.med.uc.edu> <4B02B93D.4090309@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B02B93D.4090309@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00052.txt.bz2 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.