From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16919 invoked by alias); 18 May 2002 18:08:03 -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 16912 invoked from network); 18 May 2002 18:08:02 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 18 May 2002 18:08:02 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C1E7D3E98; Sat, 18 May 2002 14:08:05 -0400 (EDT) Message-ID: <3CE69885.70607@cygnus.com> Date: Sat, 18 May 2002 11:08:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc2) Gecko/20020518 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard.Earnshaw@arm.com Cc: gdb@sources.redhat.com, Elena Zannoni Subject: Re: pseudo registers in the regcache References: <200205181048.LAA25913@cam-mail2.cambridge.arm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00231.txt.bz2 > I think the line-in-sand approach to just banning values in >> pseudo-registers post register-read is both better and easier > > > Don't get me wrong, I'm all in favour of tightening up the definitions. > What frightens me is the length of time that the "legacy" interfaces will > have to remain (and the rate at which we are growing the number of them). Knowing some of the older targets, I don't expect most to be affected at all by such a change - they already have a simple 1:1 cache layout and only raw registers. Of the others, the ones that are most affected by such a change are also the ones that most desperatly need a cleanup -> MIPS. Are there too many legacy interfaces? I just did a: $ grep legacy *.h | grep -v -e '^gdbarch' -e '^arch-' so I think we need more of them :-^ :-^ I believe most of the current legacy code is to prop up non-multi-arch architectures and get around limitations in the multi-arch framework. As the old targets go and the problems are fixed the number will start to go down. Here, yes, we've got different situtatioin. Check the thread: http://sources.redhat.com/ml/gdb/2001-03/msg00124.html for various opinions on how to approach this. (Hmm, I've been falling down on the legacy side but I have managed to doco the multi-arch process.) >> Shouldn't be too hard to do this using the tweaked regcache - that uses >> regcache->descr->nr_registers instead of NUM_REGS + NUM_PSEUDO_REGS. In >> fact [evil laughter :-)] I can think of a few other things that it could >> disallow: >> - holes in the register cache > > > Hmm, I think this will depend on who "owns" the regcache layout. If it's > a property of the "target" vector, then that is reasonable. If it's a > property of the tdep code (gdbarch vector), as I think it should be, then > I don't think it is reasonable. Sorry ``hole'' is a loose term. I'm thinking of the nasty things that can be done with register_byte() and register_raw_size(). Regsters of size zero, gaps between RawRn and RawRn+1, register_byte(PseudoRn) == register_byte (RawRm) + CONST, .... The MIPS is guilty as charged. ---- Another problem with the way things currently work. OP_REGISTER is implemented as an offset and size into the register cache. read_register_bytes is then used to read it. I should add an interface to regcache to keep that working :-( Andrew