From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17481 invoked by alias); 1 Oct 2008 14:42:32 -0000 Received: (qmail 17471 invoked by uid 22791); 1 Oct 2008 14:42:31 -0000 X-Spam-Check-By: sourceware.org Received: from s200aog12.obsmtp.com (HELO s200aog12.obsmtp.com) (207.126.144.126) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Oct 2008 14:41:48 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob012.postini.com ([207.126.147.11]) with SMTP; Wed, 01 Oct 2008 14:41:43 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id CD491DAA3 for ; Wed, 1 Oct 2008 14:41:43 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id A4E664C176 for ; Wed, 1 Oct 2008 14:41:43 +0000 (GMT) Received: from [10.18.190.51] (crx3051.cro.st.com [10.18.190.51]) by mail1.cro.st.com (MOS 3.8.7a) with ESMTP id CPY17502 (AUTH "frederic riss"); Wed, 1 Oct 2008 16:42:36 +0200 (CEST) Subject: Robustify frame_unwind_address_in_block heuristic? From: Frederic RISS To: gdb@sourceware.org Content-Type: text/plain Date: Wed, 01 Oct 2008 14:42:00 -0000 Message-Id: <1222872102.6785.516.camel@crx3051.cro.st.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00003.txt.bz2 Hi, frame_unwind_address_in_block contains the following code: /* If THIS frame is not inner most (i.e., NEXT isn't the sentinel), and NEXT is `normal' (i.e., not a sigtramp, dummy, ....) THIS frame's PC ends up pointing at the instruction fallowing the "call". Adjust that PC value so that it falls on the call instruction (which, hopefully, falls within THIS frame's code block). So far it's proved to be a very good approximation. See get_frame_type() for why ->type can't be used. */ if (next_frame->level >= 0 && get_frame_type (next_frame) == NORMAL_FRAME) --pc; and indeed, this has proved to be a very good and useful approximation. However, I'm facing a little issue with this. I've developed a custom frame unwinder for some project. It unwinds over some asm stubs which do branch to regular C code, but which also set the link register (containing the return address) to the entry of some other asm that finishes the stub's work (let's call that ret_stub). During a debug session, the dwarf2 unwinder finds the ret_stub return address and my custom unwinder kicks in to unwind to the following frame... which all seems right except for one little glitch: when printing the ret_stub frame, the above heuristic decrements the return address and points to a symbol that has no other relevance in the backtrace than being the one that happens to be linked just before ret_stub. Quite confusing for the user. I have to admit that the above is a convoluted case which shouldn't show up in a 'standard' debug session. It's also not the first time I wish that frame unwinders were more flexible/modular, but it's the first time that I wasn't able to work around the issue without patching GDB's core functionality. Would it be acceptable to add a check to the above function that checks whether pc-1 points into the same function as pc? Or maybe someone sees another way to prevent that issue? Thanks, Fred.