From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22576 invoked by alias); 9 May 2002 17:36:16 -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 22566 invoked from network); 9 May 2002 17:36:13 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 9 May 2002 17:36:13 -0000 Received: by fw-cam.cambridge.arm.com; id SAA15698; Thu, 9 May 2002 18:36:12 +0100 (BST) Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma015284; Thu, 9 May 02 18:35:23 +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 SAA23578; Thu, 9 May 2002 18:35:23 +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 SAA05353; Thu, 9 May 2002 18:35:22 +0100 (BST) Message-Id: <200205091735.SAA05353@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 13:08:32 EDT." <3CDAAD10.9000704@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 May 2002 10:36:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-05/txt/msg00085.txt.bz2 > [And I thought MIPS was bad :-)] Welcome to the real world where hardware designers get in the way, and then software developers add extra things to save some time too... > > So an FP register could contain a single, double, ... and each would be > represented differently - single, for instance, would not be stored as a > rounded double? Well, either representation might be used, and I think there exist cases where both occur. For example, a SP value just loaded from memory might be left in SP format, with a tag indicating this, or it might be held in extended precision. The only time it gets really nasty is when it comes to signalling NaNs. IEEE requires an exception if a type conversion is performed on them (but not if the value is just copied/stored/sign-flipped), so the register must hold some meta-data on the value indicating the type held, so that we can fault if required. The reason for the SFM/LFM instructions is so that a subroutine can stack such values across subroutine calls without causing exceptions to occur. > If this is the only problem, then the new REGISTER_TO_VALUE et.al. > methods should address the problem. Partly, but it puts the conversion in the Arch space, but conversion is really dependent on the Target vector, not the ABI (or not just the ABI). > Those methods, do, however, assume that the format of a register spilt > into memory is identical to the layout of the h/w register supplied by > the OS / H/W / ... Hmm, ... We might be able to achieve this, with some magic, but the format in memory isn't guaranteed to be the same for all targets. That makes use of that format undesirable: I'd much prefer to be able to use a format that was common to all ARM targets and then have both registers and memory normalized to the internal format during back-trace analysis. > > 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. > > So the way the ARM spills its FP registers into memory may not > necessarily match the equivalent h/w register? Correct, the documentation for the SFM instruction says that the format is internal to the CPU, and that the only way to recover the value is to use LFM to load it back again ;-) Of course, that's no good with a debugger, particularly a cross debugger. I don't think there is a problem with getting some documentation releases on the format that the FPA hardware uses, but I suspect that this won't necessarily match the behaviour of, say, the emulator used on ARM/Linux, since that was written without access to the details of the way the FPA does it. > > Does the ARM always spill these registers in the same way (at least for > a given ISA/ABI combination?) - if GDB is fetching a saved register from > the stack, it knows what the format is. Well, it should, but there's no absolute guarantee. In practice, some code may use SFM (storing in internal format), and other code might use STFE (store in extended format) and expect the Hardware/emulator to ignore faults when converting to/from extended precision. Although code using these methods *shouldn't* be intermixed, there's certainly no reason why multiple applications running on the same platform shouldn't use either one. I shan't bother you yet with details about how the VFP co-processor works ;-) R.