From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21626 invoked by alias); 13 Jul 2005 15:13:49 -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 21552 invoked by uid 22791); 13 Jul 2005 15:13:44 -0000 Received: from fra-del-01.spheriq.net (HELO fra-del-01.spheriq.net) (195.46.51.97) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 13 Jul 2005 15:13:44 +0000 Received: from fra-out-02.spheriq.net (fra-out-02.spheriq.net [195.46.51.130]) by fra-del-01.spheriq.net with ESMTP id j6DFDfia024429 for ; Wed, 13 Jul 2005 15:13:41 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 j6DFCxgu012034 for ; Wed, 13 Jul 2005 15:13:26 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 j6DFCioE013617 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 13 Jul 2005 15:12:50 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 16E15DE3A; Wed, 13 Jul 2005 14:46:30 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 5F274474A0; Wed, 13 Jul 2005 14:48:30 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 20D4275969; Wed, 13 Jul 2005 14:48:30 +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 67D5D47490; Wed, 13 Jul 2005 14:48:27 +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 BPI00277 (AUTH "andrew stubbs"); Wed, 13 Jul 2005 15:46:25 +0100 (BST) Date: Wed, 13 Jul 2005 15:13:00 -0000 To: "Daniel Jacobowitz" Subject: Re: Invalid registers Cc: GDB References: <20050711154926.GB30937@nevyn.them.org> <20050712173450.GA1486@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: <20050712173450.GA1486@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/msg00153.txt.bz2 On Tue, 12 Jul 2005 18:34:50 +0100, Daniel Jacobowitz wrote: > Sorry, not enough information - I'd need specifics. GCC's CFI > generally does not represent call-clobbered registers; waste of space > for a runtime unwinder. Ok, after further investigation, here's what I'm seeing. The default init_reg function, dwarf2_frame_default_init_reg, sets up the PC and stack pointer registers so that they do the right thing. Additionally, the CFI information describes how the R14 (frame pointer) and PR (saved PC) registers are saved to the stack. With this setup, 'frame 1' followed by 'info all-registers' shows the correct values (I assume) for the four registers above, and (potentially) incorrect values for everything else. So I set up a function, as follows, to tell it that anything is invalid, unless it knows otherwise: sh_dwarf2_frame_init_reg (struct gdbarch *gdbarch, int regnum, struct dwarf2_frame_state_reg *reg) { /* Mark PC as destination for the return address. */ if (regnum == PC_REGNUM) reg->how = DWARF2_FRAME_REG_RA; /* Mark stack pointer set it to the call frame address. */ else if (regnum == SP_REGNUM) reg->how = DWARF2_FRAME_REG_CFA; /* Mark all other registers as invalid. Braindead, but ok for now. */ else reg->how = DWARF2_FRAME_REG_UNDEFINED; } 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? Obviously the function above is overkill, in any case, because callee saved registers always have a useful value in them - either they have not changed or they have been saved and the CFI knows about it. I could fix that by just looking up exactly which they are and encoding it into the function above. However, it is not clear to me what to do with caller save registers. If I just set them to undefined, as above, then they will never have a value, but are there sometimes saved values for those registers (saved by the caller) and cannot CFI describe this? In short, is it always the case that call clobblered registers are unavailable? 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? Thanks Andrew Stubbs