From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11135 invoked by alias); 29 Aug 2002 15:32:55 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11096 invoked from network); 29 Aug 2002 15:32:54 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 29 Aug 2002 15:32:54 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 14E1E108F6; Thu, 29 Aug 2002 11:30:55 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15726.15919.933494.30@localhost.redhat.com> Date: Thu, 29 Aug 2002 08:36:00 -0000 To: Andrew Cagney Cc: Richard.Earnshaw@arm.com, Elena Zannoni , Kevin Buettner , gdb-patches@sources.redhat.com Subject: Re: [patch/wip] Save/restore cooked registers In-Reply-To: <3D6CF48C.3080908@ges.redhat.com> References: <200208281423.PAA16288@cam-mail2.cambridge.arm.com> <3D6CF48C.3080908@ges.redhat.com> X-SW-Source: 2002-08/txt/msg00980.txt.bz2 Andrew Cagney writes: > > > I really think we need to break this implicit link between the raw regs > > and part of the cooked regs, it just causes no-end of confusion. It's > > fine if we want to say that some cooked regs are mapped 1:1 onto part of > > the raw regcache, but that should/must be a back-end convenience, and not > > part of gdb's fundamental design (that is asking for the r0 cooked view > > may just happen to fetch the raw r0 register that is at offset zero in the > > regcache, but nothing in GDB-core should assume this). > > BTW, it turns out that nothing in core GDB is assuming this (ignoring > the CONVERTABLE mess). Elena's e500 port maped everything onto a > totally cooked register and nothing noticed. Core gdb just deals with > cooked registers (or their ulgh offset). > I think there may still be a couple of places where we are using some wrong assumptions about the register numbers. At least in target ppc code. Some harcoded 0 instead of tdep->ppc_gp0_regnum and similar things. Hopefully those will be flushed out overtime. Elena