From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29111 invoked by alias); 14 Jul 2005 09:36:14 -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 29085 invoked by uid 22791); 14 Jul 2005 09:36:07 -0000 Received: from lon-del-01.spheriq.net (HELO lon-del-01.spheriq.net) (195.46.50.97) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 14 Jul 2005 09:36:07 +0000 Received: from lon-out-03.spheriq.net ([195.46.50.131]) by lon-del-01.spheriq.net with ESMTP id j6E9Zp2t024017 for ; Thu, 14 Jul 2005 09:35:56 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-03.spheriq.net with ESMTP id j6E9Zmt8013267 for ; Thu, 14 Jul 2005 09:35:49 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id j6E9Zke3006066 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 14 Jul 2005 09:35:47 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 5644FDA42; Thu, 14 Jul 2005 09:35:45 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id DC6CD47216; Thu, 14 Jul 2005 09:37:45 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 7B07275994; Thu, 14 Jul 2005 09:37:45 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 647E14736C; Thu, 14 Jul 2005 09:37:44 +0000 (GMT) Received: from terrorhawk.bri.st.com (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.4.4-GR) with ESMTP id BPL01465 (AUTH "andrew stubbs"); Thu, 14 Jul 2005 10:35:41 +0100 (BST) Date: Thu, 14 Jul 2005 09:36:00 -0000 To: "Daniel Jacobowitz" Subject: Re: Invalid registers Cc: GDB References: <20050711154926.GB30937@nevyn.them.org> <20050712173450.GA1486@nevyn.them.org> <20050713154207.GA28768@nevyn.them.org> From: Andrew STUBBS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20050713154207.GA28768@nevyn.them.org> User-Agent: Opera M2/8.01 (Win32, build 7642) 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.3 X-SW-Source: 2005-07/txt/msg00167.txt.bz2 On Wed, 13 Jul 2005 16:42:07 +0100, Daniel Jacobowitz wrote: > On Wed, Jul 13, 2005 at 03:44:10PM +0100, Andrew STUBBS wrote: >> With this function I get different wrong behaviour. Now I get all but PC >> and R15 (stack pointer) as '*value not available*'. I had expected that >> that the CFI would override the initialised values because it knows best >> (just because it is called 'init', not 'set), but neither R14 nor PR >> have >> their true values listed despite execute_cfa_program extracting a 'how' >> value of DWARF2_FRAME_REG_SAVED_OFFSET. Clearly this is not the case, >> but >> should it be? > > Why isn't it? Please debug this, since reading the code clearly > suggests it works as you expect. See dwarf2_frame_cache. I think I have found the 'problem'. It is working as it should, but it doesn't look like it at first sight. When I set a breakpoint on a function it breaks _before_ the callee save registers have been saved (this may be a mistake, I'm not sure yet). If I step into the function a little more then the CFI kicks in and it overrides the initial settings I put in. What confused my is that there is more than one frame available at once (of course), and when debugging it is not always clear which one I am looking at, especially when it is typically the same set of registers being saved. Thank you for all your help. Apologies for being thick. Now onto the next issue .... Andrew Stubbs