From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8102 invoked by alias); 9 May 2002 17:01:05 -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 8076 invoked from network); 9 May 2002 17:01:02 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 9 May 2002 17:01:02 -0000 Received: by fw-cam.cambridge.arm.com; id SAA21668; Thu, 9 May 2002 18:01:00 +0100 (BST) Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma021301; Thu, 9 May 02 18:00:19 +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 SAA20113; Thu, 9 May 2002 18:00:18 +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 SAA02338; Thu, 9 May 2002 18:00:18 +0100 (BST) Message-Id: <200205091700.SAA02338@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 12:45:54 EDT." <3CDAA7C2.7060106@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 May 2002 10:01:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-05/txt/msg00083.txt.bz2 > > > In addition to the above, we also have the case of the CPSR register. On > > old ARM chips (or on non-thumb chips up to armv4), this register is, or > > can be mimicked as being, part of the PC. This suggests to me that the > > current decoding shenanigans that are currently hidden in some of the > > back-end code should probably be moved into the virtual-raw conversion > > layer. That is, register_convirt_{to,from}_virtual(CPSR) (or whatever > > it's really called) should be responsible for the updating of raw-PC or > > raw-CPSR as appropriate. > > Hmm, what exactly do you mean by mimicked? Can the entire register > contents be constructed from information found in the other raw/hardware > registers? If that is the case then making it a pseudo-register and > using register_{read,write} should do the trick. > > (notice - convert-to-virtual free zone). 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). 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. 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. R.