From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27342 invoked by alias); 9 May 2002 14:31:23 -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 27332 invoked from network); 9 May 2002 14:31:22 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 9 May 2002 14:31:22 -0000 Received: by fw-cam.cambridge.arm.com; id PAA09530; Thu, 9 May 2002 15:31:21 +0100 (BST) Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma009229; Thu, 9 May 02 15:31:06 +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 PAA02457; Thu, 9 May 2002 15:31:05 +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 PAA15329; Thu, 9 May 2002 15:31:05 +0100 (BST) Message-Id: <200205091431.PAA15329@cam-mail2.cambridge.arm.com> To: gdb@sources.redhat.com cc: Richard.Earnshaw@arm.com, Andrew Cagney 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: ARM and virtual/raw registers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 May 2002 07:31:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-05/txt/msg00081.txt.bz2 Ok, so it's clear that the current ARM code for handling virtual and raw registers is wrong... So the question is, what does it need to be? The answer is that I'm not quite sure, since there are a number of factors involved here. 1) FPA registers are multi-precision -- that is, they are modal, holding information about the type of result in the register at any particular time. The extra information is used to enable correct support of type conversions with signalling NaNs. 2) The format of that information can depend on the hardware present, or, if absent, on the emulator being used (different emulators handle this in different ways). 3) Some of the emulators use three words to hold the raw information, some use four. RDP returns uses four words. 4) When a floating point value is stored in memory the format of that memory may depend on the instruction used to store it. For example, the sfmfd instruction used in a prologue sequence will store three words (as would stfe), but there may be information in the unused bits that indicates the type of the value in the register. The format of this memory may, or may not, be the same as the three-word register information mentioned in 3) above. 5) All of the above is poorly documented ;-( 6) Selecting the correct conversion routine may involve some inspired guess-work :-) 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. Comments? R.