From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4732 invoked by alias); 13 Jul 2005 20:27:22 -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 4713 invoked by uid 22791); 13 Jul 2005 20:27:18 -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 20:27:18 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1Dsnp6-0002JN-4f; Wed, 13 Jul 2005 16:27:16 -0400 Date: Wed, 13 Jul 2005 20:27:00 -0000 From: Daniel Jacobowitz To: Andrew STUBBS Cc: GDB Subject: Re: Invalid registers Message-ID: <20050713202716.GA8536@nevyn.them.org> Mail-Followup-To: Andrew STUBBS , GDB References: <20050711154926.GB30937@nevyn.them.org> <20050712173450.GA1486@nevyn.them.org> <20050713154207.GA28768@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/msg00157.txt.bz2 On Wed, Jul 13, 2005 at 05:14:02PM +0100, Andrew STUBBS wrote: > 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. Sorry, at some point you got me turned around with my own terminology. Let me try again, more coherently. CFI describes saved registers. It can describe any saved register; typically, however, it only describes enough state to unwind to the state as-of any call instruction, i.e. to describe any frame on the stack. At a call instruction there is still code in the caller to be executed which will reload the caller saved registers; that code can be freely scheduled, it is not part of the call sequence. So typically it is not described. Those registers are dead at the call site and given interesting values again later. While the registers may be conceptually unavailable, the variables in them are not - if your compiler emits good location lists, they'll reflect the stack slots used. So the value for PR we want to recover while unwinding is the value it had "at the call site" - generally unavailable. But we can figure out what it was just after the call site, where the prologue will often have saved it, and use that to determine where to unwind to. -- Daniel Jacobowitz CodeSourcery, LLC