From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25696 invoked by alias); 24 May 2005 08:15:44 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 25619 invoked by uid 22791); 24 May 2005 08:15:32 -0000 Received: from fra-del-03.spheriq.net (HELO fra-del-03.spheriq.net) (195.46.51.99) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 24 May 2005 08:15:32 +0000 Received: from fra-out-02.spheriq.net (fra-out-02.spheriq.net [195.46.51.130]) by fra-del-03.spheriq.net with ESMTP id j4O8FUQ1028078 for ; Tue, 24 May 2005 08:15:30 GMT Received: from fra-cus-02.spheriq.net (fra-cus-02.spheriq.net [195.46.51.38]) by fra-out-02.spheriq.net with ESMTP id j4O8FCtP029204 for ; Tue, 24 May 2005 08:15:13 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-02.spheriq.net with ESMTP id j4O8FQeh010838 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 24 May 2005 08:15:28 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 33841DA46; Tue, 24 May 2005 08:15:26 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id C7790473B9; Tue, 24 May 2005 08:17:02 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 84C23759B9; Tue, 24 May 2005 08:17:02 +0000 (UTC) Received: from mail2.gnb.st.com (mail2.gnb.st.com [164.129.119.59]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D8F6B473AF; Tue, 24 May 2005 08:17:01 +0000 (GMT) Received: from st.com (pcx0003.gnb.st.com [164.129.118.67]) by mail2.gnb.st.com (MOS 3.4.4-GR) with ESMTP id BGU07308 (AUTH lyon); Tue, 24 May 2005 10:15:23 +0200 (CEST) Message-ID: <4292E29B.A1FE162E@st.com> Date: Tue, 24 May 2005 08:15:00 -0000 From: Christophe LYON MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sourceware.org Subject: Re: Handling the 'next' command on a variable-length bundles target References: <4291F882.BC2F3699@st.com> <20050523154546.GA3028@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 2.2.1 X-SW-Source: 2005-05/txt/msg00297.txt.bz2 > > I would like to have your inputs on possible > > clean ways of handling this. > > I am considering modyfing the way 'next' and > > 'stepi' memorize the frame in this specific > > case, but this is far from being generic. > > Maybe it is too specific to think of a generic > > fix, but maybe some of you have similar > > features? > > This is not a missing feature in GDB, it's a bug in your target. The > ID for a frame should be constant throughout the function. You need to > use either code analysis or DWARF-2 style unwind information to have a > constant ID for the frame; in this case, probably the unadjusted SP. > Well, I am not (yet) very familiar with debugging optimized code. What do you mean by "code analysis" ? Currently, the recorded frame contains the unadjusted SP, but upon return from the call SP has been modified and the current frame is thus different from the recorded one. As you say the frame ID should be the unadjusted SP, I don't understand exactly how: you mean that after the call the frame ID should also contain the unadjusted SP? Thanks, Christophe.