From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2297 invoked by alias); 26 Jul 2006 22:25:15 -0000 Received: (qmail 2284 invoked by uid 22791); 26 Jul 2006 22:25:14 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 26 Jul 2006 22:25:12 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G5roQ-0007mE-3h; Wed, 26 Jul 2006 18:25:06 -0400 Date: Wed, 26 Jul 2006 22:25:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: andrew.stubbs@st.com, gdb-patches@sourceware.org Subject: Re: [RFC] Move the frame zero PC check earlier Message-ID: <20060726222506.GA29619@nevyn.them.org> Mail-Followup-To: Mark Kettenis , andrew.stubbs@st.com, gdb-patches@sourceware.org References: <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> <200607221122.k6MBMrdP000084@elgar.sibelius.xs4all.nl> <20060724193245.GB13612@nevyn.them.org> <200607262215.k6QMFTQT019655@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607262215.k6QMFTQT019655@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes 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/msg00393.txt.bz2 On Thu, Jul 27, 2006 at 12:15:29AM +0200, Mark Kettenis wrote: > > Where would the PC==0 test be applied? I and several others in > > this thread have said that it makes sense in every case for every > > platform - that's why I wanted it in frame.c, rather than in each > > individual unwinder. I can't tell from this paragraph whether we've > > convinced you, or whether you would push it out to the individual > > architectures to decide. I'm unhappy with individual architecture > > knobs for basically the same reason we've agreed it shouldn't be a user > > knob. > > I though I have been very clear: PC == 0 is unacceptable as a generic > condition for terminating stack frames. So yes, this will be pushed > into the individual architectures. That's good since it forces people > to think about the proper termination condition for their ISA/ABI. I guess I was hoping we'd convinced you. I demonstrated that at least one of the architectures you listed as not having use for this convention, under at least one operating system, actually did use it. Jim and Joel and Andrew all piped up to support using it universally. But if you're dead set against it, I don't see any way forward except to concede. This means I'm going to keep getting bug reports with the same solutions on different architectures for a while :-( Oh 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. > > > > I suspect that OUTERMOST_FRAME would be a lot of trouble. There's a > > lot of checks on frame types that look for "abnormal" frames via > > ->type != NORMAL_FRAME; but a function called by an OUTERMOST_FRAME was > > a normal call, just like a function called by a NORMAL_FRAME. That's > > why I suggested a new unwinder method in struct frame_unwind. > > Actually there is only a limited number of such tests in our tree: a > couple of them in frame.c, and two in s390-tdep.c. Many of the checks > in frame.c actually deal with stuff that we might want to do > differently for OUTERMOST_FRAME. The checks in s390-tdep.c both have > this FIXME on them: You're right - I thought there were far more than there actually are. I guess this would work. Maybe we need a few predicate functions for these types... > /* FIXME: cagney/2004-05-01: This sanity check shouldn't be needed, > instead the code should simpliy rely on its analysis. */ Andrew and I argued about this comment several times. I disagree with it, and in fact have various patches floating around to do similar tests on more architectures. It's an extremely useful technique, done carefully. -- Daniel Jacobowitz CodeSourcery