From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4037 invoked by alias); 1 Oct 2008 15:58:29 -0000 Received: (qmail 4020 invoked by uid 22791); 1 Oct 2008 15:58:27 -0000 X-Spam-Check-By: sourceware.org Received: from s200aog13.obsmtp.com (HELO s200aog13.obsmtp.com) (207.126.144.127) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Oct 2008 15:57:44 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob013.postini.com ([207.126.147.11]) with SMTP; Wed, 01 Oct 2008 15:57:40 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 3CC5ADA80; Wed, 1 Oct 2008 15:57:36 +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 1B9DE4C1F8; Wed, 1 Oct 2008 15:57:36 +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 CPY20156 (AUTH "frederic riss"); Wed, 1 Oct 2008 17:58:29 +0200 (CEST) Subject: Re: Robustify frame_unwind_address_in_block heuristic? From: Frederic RISS To: Joel Brobecker Cc: gdb@sourceware.org In-Reply-To: <20081001152828.GG3748@adacore.com> References: <1222872102.6785.516.camel@crx3051.cro.st.com> <20081001144756.GA19452@caradoc.them.org> <20081001152828.GG3748@adacore.com> Content-Type: text/plain; charset=UTF-8 Date: Wed, 01 Oct 2008 15:58:00 -0000 Message-Id: <1222876655.6785.549.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/msg00008.txt.bz2 Le mercredi 01 octobre 2008 à 08:28 -0700, Joel Brobecker a écrit : > > 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. Yeah, I might throw another unwinder in the game that 'proxies' the dwarf frame and returns ret_stub+1 as PC. Not really nice but it 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? Well, when the user sees ret_from_irq_stub in the backtrace, she can understand something... when she sees frobnicate_with_my_bits (or some other unrelated stuff with a not-so-funny name) she's totally lost. Fred