From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18108 invoked by alias); 1 Oct 2008 15:26:39 -0000 Received: (qmail 18095 invoked by uid 22791); 1 Oct 2008 15:26:38 -0000 X-Spam-Check-By: sourceware.org Received: from s200aob14.obsmtp.com (HELO psmtp.com) (207.126.144.118) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Oct 2008 15:25:52 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob014.postini.com ([207.126.147.11]) with SMTP; Wed, 01 Oct 2008 15:25:47 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 60D38DAC9; Wed, 1 Oct 2008 15:25:45 +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 3A9E24C1C7; Wed, 1 Oct 2008 15:25:45 +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 CPY19164 (AUTH "frederic riss"); Wed, 1 Oct 2008 17:26:38 +0200 (CEST) Subject: Re: Robustify frame_unwind_address_in_block heuristic? From: Frederic RISS To: Daniel Jacobowitz Cc: gdb@sourceware.org In-Reply-To: <20081001144756.GA19452@caradoc.them.org> References: <1222872102.6785.516.camel@crx3051.cro.st.com> <20081001144756.GA19452@caradoc.them.org> Content-Type: text/plain; charset=UTF-8 Date: Wed, 01 Oct 2008 15:26:00 -0000 Message-Id: <1222874744.6785.530.camel@crx3051.cro.st.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit 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/msg00005.txt.bz2 Le mercredi 01 octobre 2008 à 10:47 -0400, Daniel Jacobowitz a écrit : > On Wed, Oct 01, 2008 at 04:41:42PM +0200, Frederic RISS wrote: > > 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? > > No. That's exactly the issue this code was written to handle :-) Really? I always thought the main motivation was showing the call site in the backtrace rather than the return site (when they are different). But yes, I hadn't thought about the handling of noreturn functions which are rather more common than my stubs :-) > > Or maybe someone sees another way to prevent that issue? > > I don't see how to generically handle this case unless you can > distinguish it from this example: > > my_function: > do_stuff > call noreturn_function > unrelated_function: > do_unrelated_stuff > > 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. Of course we can't :-(, at least not in a generic way. I know the exceptions to the rule in my application, but unfortunately there's no way to feed this information into the frame unwinding machinery. Well, I guess I need to stick with my ugly patch to frame.c. Thanks for the fast answer! Fred.