From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7980 invoked by alias); 13 Jul 2005 16:16:40 -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 7941 invoked by uid 22791); 13 Jul 2005 16:16:32 -0000 Received: from lon-del-03.spheriq.net (HELO lon-del-03.spheriq.net) (195.46.50.99) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 13 Jul 2005 16:16:32 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-03.spheriq.net with ESMTP id j6DGGTVS027552 for ; Wed, 13 Jul 2005 16:16:29 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-01.spheriq.net with ESMTP id j6DGGSeN019339 for ; Wed, 13 Jul 2005 16:16:29 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id j6DGGRiU017722 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 13 Jul 2005 16:16:27 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 D67E8DA43; Wed, 13 Jul 2005 16:16:22 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 327FA475A1; Wed, 13 Jul 2005 16:18:23 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id E563175969; Wed, 13 Jul 2005 16:18:22 +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 49C8B47592; Wed, 13 Jul 2005 16:18:19 +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 BPI01221 (AUTH "andrew stubbs"); Wed, 13 Jul 2005 17:16:17 +0100 (BST) Date: Wed, 13 Jul 2005 16:16: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/msg00155.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'll see what I can find. >> I know the PR register is >> technically caller save, but has a CFI entry in my test program, but >> then >> in practice PR is really treated as callee save anyway. Is that just a >> special case? > > I would need to see the CFI, sorry - I can't follow exactly what you > mean. The SH ABI lists the PR register (in which the PC is saved by a branch to subroutine) as caller save. This is true because a function has to save it before calling a subroutine. However, in practice it can be viewed as a callee save register because all non-leaf functions save it in the function prologue. GCC appears to be emitting CFI information for PR as if it was callee save. You say that there should be no CFI for caller saved registers, so I'll take that as answering my question. Thanks Andrew Stubbs