From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32116 invoked by alias); 29 Nov 2009 18:48:17 -0000 Received: (qmail 32093 invoked by uid 22791); 29 Nov 2009 18:48:12 -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; Sun, 29 Nov 2009 18:48:07 +0000 Received: from bromo.med.uc.edu (localhost.localdomain [127.0.0.1]) by bromo.med.uc.edu (Postfix) with ESMTP id DB42FB0048; Sun, 29 Nov 2009 13:48:04 -0500 (EST) Received: (from howarth@localhost) by bromo.med.uc.edu (8.14.3/8.14.3/Submit) id nATIm4cV013513; Sun, 29 Nov 2009 13:48:04 -0500 Date: Sun, 29 Nov 2009 18:48:00 -0000 From: Jack Howarth To: Andrew Haley Cc: borlum , java@gcc.gnu.org Subject: Re: [patch] Fix oddity in personality routine Message-ID: <20091129184804.GA13502@bromo.med.uc.edu> References: <4B02B93D.4090309@redhat.com> <20091117170659.GA20342@bromo.med.uc.edu> <4B02D9BB.8020403@redhat.com> <20091117173701.GA20964@bromo.med.uc.edu> <26540588.post@talk.nabble.com> <4B0FAC91.5030401@redhat.com> <20091127215118.GA6568@bromo.med.uc.edu> <4B10FECE.8010600@redhat.com> <20091129174835.GB13043@bromo.med.uc.edu> <4B12B6D9.5050008@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B12B6D9.5050008@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/msg00074.txt.bz2 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.