From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12497 invoked by alias); 9 May 2002 17:08:32 -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 12488 invoked from network); 9 May 2002 17:08:31 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 9 May 2002 17:08:31 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 40BEB3DB9; Thu, 9 May 2002 13:08:32 -0400 (EDT) Message-ID: <3CDAAD10.9000704@cygnus.com> Date: Thu, 09 May 2002 10:08:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard.Earnshaw@arm.com Cc: gdb@sources.redhat.com Subject: Re: ARM and virtual/raw registers References: <200205091431.PAA15329@cam-mail2.cambridge.arm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00084.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. [And I thought MIPS was bad :-)] 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? I think the Alpha does this for int values - it has some really strange to/from register/int code. If this is the only problem, then the new REGISTER_TO_VALUE et.al. methods should address the problem. 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, ... > 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. So the way the ARM spills its FP registers into memory may not necessarily match the equivalent h/w register? 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. > 5) All of the above is poorly documented ;-( > > 6) Selecting the correct conversion routine may involve some inspired > guess-work :-) Andrew