From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17038 invoked by alias); 13 Jul 2005 15:42:13 -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 17023 invoked by uid 22791); 13 Jul 2005 15:42:10 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 13 Jul 2005 15:42:10 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1DsjN9-0007Wp-Tt; Wed, 13 Jul 2005 11:42:08 -0400 Date: Wed, 13 Jul 2005 15:42:00 -0000 From: Daniel Jacobowitz To: Andrew STUBBS Cc: GDB Subject: Re: Invalid registers Message-ID: <20050713154207.GA28768@nevyn.them.org> Mail-Followup-To: Andrew STUBBS , GDB References: <20050711154926.GB30937@nevyn.them.org> <20050712173450.GA1486@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg00154.txt.bz2 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. > 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. Correct. > 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 No, it can't. CFI describes the state at the call instruction, from the point of view of the called function. It's not conceptually impossible to describe caller saved registers, but no compiler I'm familiar with does it... > call clobblered registers are unavailable? I know the PR register is Only if they are clobbered. That's why GDB defaults to showing them anyway; it is often useful, although sometimes wrong. > 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. -- Daniel Jacobowitz CodeSourcery, LLC