From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20397 invoked by alias); 17 Nov 2009 16:18:29 -0000 Received: (qmail 20385 invoked by uid 22791); 17 Nov 2009 16:18:27 -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 16:17:24 +0000 Received: from bromo.med.uc.edu (localhost.localdomain [127.0.0.1]) by bromo.med.uc.edu (Postfix) with ESMTP id 53B55B005D; Tue, 17 Nov 2009 11:17:22 -0500 (EST) Received: (from howarth@localhost) by bromo.med.uc.edu (8.14.3/8.14.3/Submit) id nAHGHLK4020100; Tue, 17 Nov 2009 11:17:21 -0500 Date: Tue, 17 Nov 2009 16:18:00 -0000 From: Jack Howarth To: Andrew Haley Cc: java@gcc.gnu.org Subject: Re: [patch] Fix oddity in personality routine Message-ID: <20091117161721.GA19635@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/msg00049.txt.bz2 On Tue, Nov 17, 2009 at 02:54:53PM +0000, Andrew Haley wrote: > Jack Howarth wrote: > > > 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. > > 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. > Andrew, At which points should I be sampling with 'x cur_context.ra'? Is there a particular breakpoint that would be useful to set in order to do this? Also, would it help if I recompiled libgcj with -O0 as well? Jack > > Andrew.