From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2174 invoked by alias); 2 Jul 2003 19:12:53 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2146 invoked from network); 2 Jul 2003 19:12:53 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 2 Jul 2003 19:12:53 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19Xn39-0002NC-00 for ; Wed, 02 Jul 2003 14:13:51 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19Xn29-0006OX-00 for ; Wed, 02 Jul 2003 15:12:49 -0400 Date: Wed, 02 Jul 2003 19:12:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: Add frame_is_callee_p(), use in dwarf2-frame.c? Message-ID: <20030702191249.GA24531@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <3F0328AF.9080706@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0328AF.9080706@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00050.txt.bz2 On Wed, Jul 02, 2003 at 02:47:11PM -0400, Andrew Cagney wrote: > Hello, > > Following up the comment: > > > /* Unwind the PC. > > > > Note that if NEXT_FRAME is never supposed to return (i.e. a call > > to abort), the compiler might optimize away the instruction at > > NEXT_FRAME's return address. As a result the return address will > > point at some random instruction, and the CFI for that > > instruction is probably wortless to us. GCC's unwinder solves > > this problem by substracting 1 from the return address to get an > > address in the middle of a presumed call instruction (or the > > instruction in the associated delay slot). This should only be > > done for "normal" frames and not for resume-type frames (signal > > handlers, sentinel frames, dummy frames). > > > > We don't do what GCC's does here (yet). It's not clear how > > reliable the method is. There's also a problem with finding the > > right FDE; see the comment in dwarf_frame_p. If dwarf_frame_p > > selected this frame unwinder because it found the FDE for the > > next function, using the adjusted return address might not yield > > a FDE at all. The problem isn't specific to DWARF CFI; other > > unwinders loose in similar ways. Therefore it's probably > > acceptable to leave things slightly broken for now. */ > > fs->pc = frame_pc_unwind (next_frame); > > > Given MichaelC's flurry of bugs on this, should the fix be added to 6? > > As for the dwarf2_frame_p test, outch! Any ideas? Change the parameter > to ``address_in_block'', instead of a PC? That sounds reasonable... > Regardless, for a ``normal frame'' test, I'd like to suggest > ``frame_is_callee_p()'' as something suitable descriptive. Thoughts? You've leapt ahead of me again. What would frame_is_callee_p mean? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer