From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14382 invoked by alias); 4 Apr 2008 11:25:47 -0000 Received: (qmail 14374 invoked by uid 22791); 4 Apr 2008 11:25:46 -0000 X-Spam-Check-By: sourceware.org Received: from s200aog14.obsmtp.com (HELO s200aog14.obsmtp.com) (207.126.144.128) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 04 Apr 2008 11:25:19 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob014.postini.com ([207.126.147.11]) with SMTP; Fri, 04 Apr 2008 11:25:16 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 085CFDA7E for ; Fri, 4 Apr 2008 11:25:15 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 5D9674C1B9 for ; Fri, 4 Apr 2008 11:25:15 +0000 (GMT) Received: from [164.129.14.85] (bri1017.bri.st.com [164.129.14.85]) by mail1.bri.st.com (MOS 3.7.5a-GA) with ESMTP id CJY52181 (AUTH antony); Fri, 4 Apr 2008 12:24:22 +0100 (BST) Message-ID: <47F6101A.1020505@st.com> Date: Fri, 04 Apr 2008 11:43:00 -0000 From: Antony KING User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Problem setting registers if stack point or frame pointer is 0 References: <47F54DAD.9070302@st.com> <20080403214752.GA20869@caradoc.them.org> In-Reply-To: <20080403214752.GA20869@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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-04/txt/msg00040.txt.bz2 Thanks for the information. Is the hack you mention the suggestion (you gave to my colleague) in the following response? http://www.cygwin.com/ml/gdb-patches/2006-05/msg00018.html We did have this patch applied at some point in earlier versions of our GDB but we seem to have lost it along the way :-(. Anyway it looks to be a better solution than the one I suggested (as every user of frame_find_by_id() will benefit), so I will reapply it to our version of GDB (unless you have a better version). Cheers, Antony. Daniel Jacobowitz wrote: > On Thu, Apr 03, 2008 at 10:35:41PM +0100, Antony KING wrote: >> Hi, >> >> I have a problem trying to set a CPU register (using the GDB convenience >> variable mechanism) if the stack pointer (SP) or frame pointer (FP) CPU >> registers are 0. For example on an SH-4 device, where the FP register is >> R14 and the SP register is R15, I see the following error from GDB >> (6.7.1): > > This is an unfortunate design problem in GDB. You've found the right > comment, but in fact the comment lies. > > /* ZERO denotes the null frame, let the caller decide what to do > about it. Should it instead return get_current_frame()? */ > > It doesn't denote just the null frame (nothing running). It also > denotes the last frame (can not unwind past here, outermost). We've > really got to get rid of that ambiguity. > > I use a terrible hack in find_frame_by_id in our tools, since I > still haven't found time to return to this problem :-(