From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19865 invoked by alias); 1 Oct 2008 15:29:09 -0000 Received: (qmail 19857 invoked by uid 22791); 1 Oct 2008 15:29:08 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Oct 2008 15:28:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 507832A964B; Wed, 1 Oct 2008 11:28:31 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MkkuaVFo3LgM; Wed, 1 Oct 2008 11:28:31 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 043632A9648; Wed, 1 Oct 2008 11:28:31 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id E75D5E7ACD; Wed, 1 Oct 2008 08:28:28 -0700 (PDT) Date: Wed, 01 Oct 2008 15:29:00 -0000 From: Joel Brobecker To: Frederic RISS , gdb@sourceware.org Subject: Re: Robustify frame_unwind_address_in_block heuristic? Message-ID: <20081001152828.GG3748@adacore.com> References: <1222872102.6785.516.camel@crx3051.cro.st.com> <20081001144756.GA19452@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081001144756.GA19452@caradoc.them.org> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00007.txt.bz2 > But there's rarely anything to handle the special kind of call in your > 'returned-to' function, so from what's on the stack, I don't know how > we can tell. Perhaps there is some information either in the ret_stub or the called function that would allow get_frame_pc () to detect it, and thus massage the returned value by adding 1 so that get_frame_address_in_block returns the address at the start of the stub. Seems pretty hacky, but might work. That being said, the backtrace must be strange, because instead of seeing the real caller in the backtrace, you see the ret_stub? -- Joel