From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7237 invoked by alias); 10 May 2002 10:45:06 -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 7216 invoked from network); 10 May 2002 10:45:03 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 10 May 2002 10:45:03 -0000 Received: by fw-cam.cambridge.arm.com; id LAA05851; Fri, 10 May 2002 11:45:00 +0100 (BST) Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma005751; Fri, 10 May 02 11:44:49 +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 LAA26921; Fri, 10 May 2002 11:44:49 +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 LAA25709; Fri, 10 May 2002 11:44:48 +0100 (BST) Message-Id: <200205101044.LAA25709@cam-mail2.cambridge.arm.com> To: Andrew Cagney cc: Richard.Earnshaw@arm.com, gdb@sources.redhat.com 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: ARM and virtual/raw registers In-reply-to: Your message of "Thu, 09 May 2002 14:52:13 EDT." <3CDAC55D.1040104@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 May 2002 03:45:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-05/txt/msg00099.txt.bz2 (notice - convert-to-virtual free zone). > > (and how I'm quietly eliminating it :-) > :-) > > In the case where the real register does not exist (arm2, arm3), or when > > the register doesn't exist in the current operating mode (arm6, arm7 -- > > though not arm7tdmi, arm8 and sa1 when running in apcs-26 mode), then the > > CPSR is part of the PC and we mimic its existence within GDB; so yes, in > > that case it is a virtual register. > > > But when we are running in pure apcs-32 mode, then CPSR is a separate > > register (with additional bits defined). > > In APCS-32 mode, is there any overlap of information between it and the PC? No, the bits in the PC that were used for the CPSR are now used for addressing the full 4Mb of memory. However, I agree that this should somehow be done with the pseudo mechanism if the physical register doesn't exist. > > > The more I think about it, the more I think that the raw<->virtual > > translation is in the wrong part of GDB. Shouldn't this be part of the > > Target interface? Then conversion to/from virtual format would happen as > > data is passed to/from the inferior, and the rest of GDB would only use > > the virtual format. > > Yes, I agree that raw<->virtual is wrong; but no, it shouldn't be pushed > down below the target. > > > As I understand it, this would clean up the MIPS issue entirely -- when > > talking to a target that supplies additional bits for a register, the > > target layer would strip these off/add them back, and the rest of gdb > > wouldn't have to worry about it. > > Have a look at the SH5 patch. I think this gets it right. > > The first cut at all this had the target using supply_register() to fill > in missing values in from below the cache - turns out this makes > coherency hard. The current revision uses register_{read,write} above > the cache to do this, thus eliminating redundant information in the cache. > > For the SH5, the raw register cache contains SHmedia (32/64 bit?) > registers (as that is what the raw hardware has). Pseudo-registers, and > register_{read,write} are then used to map SHcompact (16/32?) registers > onto the corresponding raw registers. OK, I'll buy the argument that the cache should contain exactly the physical registers and nothing else (ie no pseudos). That is, there is a one-one mapping between the registers in the cache and the registers in the machine. The issue is what the format of those registers in the cache should be. My feeling is that they should be normalized (I deliberately use a different word from virtualized), so that regardless of the access mechanism used in the target vector -- again note, not the gdbarch vector-- (eg, does the protocol transfer four words, or only three), the format of the values in the cache are the same. Now obviously for this to work, then there must exist mapping functions f() and f'() that convert between the two formats with no loss of information for the useful domain of the register. With the above constraints, I can't see how that would lead to any coherency issues. Now, ideally, this normalized format would be the same as the virtualized format (so that no further conversion was needed), and that would also match the memory format used by a register save to the stack frame. However, on the ARM, we can't really predict what that format will be -- it could well depend on the instructions used to generate the frame (STFE or SFM). Further, we probably also need to know the type of FPE/FPA in use by the target to understand that format, and that can only be done by interrogating the FPSR (floating point status register). So, I think we also need additional conversion routines, say g() and g'() that convert to and from memory format -- we may even need multiple such functions, since if we are reading from a memory location created with stfe we may need a different conversion from when a memory location was created with sfm. These conversions ARE part of the arch vector, but for most targets will be identity operations. Now obviously, in order to do all this correctly the stack-frame groveller will have to record the information as it unwinds the stack in some private data; but creating this information is part of the stack-unwinding process. R.