From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18860 invoked by alias); 18 May 2002 10:49:51 -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 18852 invoked from network); 18 May 2002 10:49:44 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 18 May 2002 10:49:44 -0000 Received: by fw-cam.cambridge.arm.com; id LAA03053; Sat, 18 May 2002 11:49:43 +0100 (BST) Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma002849; Sat, 18 May 02 11:48:55 +0100 Received: from cam-mail2.cambridge.arm.com (cam-mail2.cambridge.arm.com [172.16.1.91]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id LAA09668; Sat, 18 May 2002 11:48:53 +0100 (BST) Received: from sun18.cambridge.arm.com (sun18.cambridge.arm.com [172.16.2.18]) by cam-mail2.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id LAA25913; Sat, 18 May 2002 11:48:53 +0100 (BST) Message-Id: <200205181048.LAA25913@cam-mail2.cambridge.arm.com> To: Andrew Cagney cc: Richard.Earnshaw@arm.com, gdb@sources.redhat.com, Elena Zannoni Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: pseudo registers in the regcache In-reply-to: Your message of "Fri, 17 May 2002 12:48:03 EDT." <3CE53443.6070807@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 May 2002 03:49:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-05/txt/msg00227.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). > > 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. Forcing the tdep code to modify it's understanding of the regcache layout for each possible target sounds like a nightmare. And since not every target can supply all the registers that might exist in an ARM system we are bound to be left with holes at times. My preferred solution would be for tdep code (gdbarch) to supply a standard layout of the regcache space, and then have the target vector code notify the regcache layer which of those registers it is able to supply (or unable to supply if that is more appropriate). > - differing register virtual and raw sizes That one doesn't worry me any more :-) R.