From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11219 invoked by alias); 2 Jul 2003 18:47:13 -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 11212 invoked from network); 2 Jul 2003 18:47:13 -0000 Received: from unknown (HELO localhost.redhat.com) (66.187.230.200) by sources.redhat.com with SMTP; 2 Jul 2003 18:47:13 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3129D2B5F for ; Wed, 2 Jul 2003 14:47:11 -0400 (EDT) Message-ID: <3F0328AF.9080706@redhat.com> Date: Wed, 02 Jul 2003 18:47:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: Add frame_is_callee_p(), use in dwarf2-frame.c? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg00046.txt.bz2 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? Regardless, for a ``normal frame'' test, I'd like to suggest ``frame_is_callee_p()'' as something suitable descriptive. Thoughts? Andrew