From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31875 invoked by alias); 22 Jul 2006 11:23:07 -0000 Received: (qmail 31861 invoked by uid 22791); 22 Jul 2006 11:23:02 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 22 Jul 2006 11:22:57 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k6MBMs6Y003293; Sat, 22 Jul 2006 13:22:54 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6) with ESMTP id k6MBMs17009149; Sat, 22 Jul 2006 13:22:54 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6/Submit) id k6MBMrdP000084; Sat, 22 Jul 2006 13:22:53 +0200 (CEST) Date: Sat, 22 Jul 2006 11:23:00 -0000 Message-Id: <200607221122.k6MBMrdP000084@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: andrew.stubbs@st.com CC: gdb-patches@sourceware.org In-reply-to: <44C0F828.4090807@st.com> (message from Andrew STUBBS on Fri, 21 Jul 2006 16:52:08 +0100) Subject: Re: [RFC] Move the frame zero PC check earlier References: <1147815745.3672.163.camel@dufur.beaverton.ibm.com> <20060517155729.GF27234@adacore.com> <446C3EB3.1040606@st.com> <1147969938.3672.168.camel@dufur.beaverton.ibm.com> <200605182004.k4IK49Eh003764@elgar.sibelius.xs4all.nl> <200605202129.k4KLT4g4014877@elgar.sibelius.xs4all.nl> <20060521020434.GA9432@nevyn.them.org> <44C0F828.4090807@st.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00307.txt.bz2 > Date: Fri, 21 Jul 2006 16:52:08 +0100 > From: Andrew STUBBS > > This is a feature I would like to see. Thanks Andrew, for reminding us. > Daniel Jacobowitz wrote: > > On Sat, May 20, 2006 at 11:29:04PM +0200, Mark Kettenis wrote: > >> I actually think that something like that is the way to go. It's > >> closely related to what Dan wrote about in: > >> > >> http://sourceware.org/ml/gdb/2006-05/msg00109.html > >> > >> and I'd like to have a go at implementing option #2 in that mail. > > > > That (the frame unwinder end-of-stack method) wouldn't actually help > > with this problem; that's why I sent the two separately (they were > > originally the same message when I was writing it). The architecture > > unwinder could report a saved pc of zero as terminating the stack, but > > in all the cases I'm interested in, the DWARF-2 unwinder is actually > > used for the bottom frame. But the "having a saved pc of zero" is only one of the conventions used for terminating the frame chain. So the DWARF-2 unwinder would still fail to do the right thing for ISA/ABI's that use a different convention. So I think we need an ISA/ABI-specefic callback to determine whether a frame is the outermost frame, just like we already have for signal trampolines. This actually matches the following idea I had pretty well: The outermost frame is special, just like sigtramp and dummy frames. Why not introduce a new frame type OUTERMOST_FRAME and make get_prev_frame() return NULL if that's the type of THIS_FRAME's? This would require some changes to the current frame unwinder infrastructure, since the type is currently hardcoded into the unwinder. That would have the additional benefit that we could get rid of the bogosity that we have multiple frame unwinder definitions in the DWARF-2 unwinder just to handle signal trampolines. Thoughts? Mark