From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14849 invoked by alias); 28 Jul 2003 08:41:33 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14827 invoked from network); 28 Jul 2003 08:41:29 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.54) by sources.redhat.com with SMTP; 28 Jul 2003 08:41:29 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id JAA04853; Mon, 28 Jul 2003 09:41:21 +0100 (BST) Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id h6S8fLd03396; Mon, 28 Jul 2003 09:41:21 +0100 Message-Id: <200307280841.h6S8fLd03396@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Andrew Cagney cc: amichelotti@ipitec.it, Daniel Jacobowitz , Richard Earnshaw , gdb-patches@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: internal error reading f0-f7 registers in arm-elf targets. In-reply-to: Your message of "Sun, 27 Jul 2003 15:25:17 EDT." <3F24271D.9040304@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Jul 2003 08:41:00 -0000 From: Richard Earnshaw X-SW-Source: 2003-07/txt/msg00490.txt.bz2 > > > Secondly, just changing the number is hardly correct. Patches have to > > fix the problem, not just hide around it by making an incorrect change; > > and the comment is still accurate. > > Well arm_register_virtual_size() and arm_register_virtual_type() > disagree, outch! > > BTW, see also: > http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1276 > > I get the feeling that FP_REGISTER_VIRTUAL_SIZE has nothing to do with > FP_REGISTER_RAW_SIZE and arm_register_virtual_size should return the raw > value. Well ok, technically, arm_register_virtual_size, > arm_register_raw_size and arm_register_virtual_type should all be folded > into arm_register_type. > > Looking at FP_REGISTER_VIRTUAL_SIZE that really only comes into play > when the Arm doesn't even have H/W floating point registers. See > arm-linux-tdep.c where it pushes on a double fp value on the stack. > > On the other hand, the Arm prologue analysis code, appears to assume > that those registers are always 12 bytes. Look for: > /* stfe f?, [sp, -#c]! */ > store floating point extended (i.e. 12 bytes) > /* sfmfd f0, 4, [sp!] */ > store 12 byte floating point registers > so it things 12 byte floats are stored. > That's because 12 bytes are stored on the stack for each FP register. This is all somewhat complicated. The FPA has support for IEEE extended-precision arithmetic, but it's never used by the compiler/ABI. However, to ensure that register values are correctly preserved across function calls and don't generate conversion traps in the prologue, they have to be saved in either in extended precision or in internal format by the prologue. Old implementations of the FPE (the Emulator for the FPA) did not have support for SFM instructions, so values were stored out in extended precision (STFE), and that mode was configured not to trap on conversion. The FPA (and newer versions of the FPE) have the store-float-multiple (SFM) which stores out the registers in their internal form to guarantee that things won't trap. This all means that to correctly unwind floating point values we either need to execute the LFM instructions (not generally possible in remote/cross debugging) or understand the internal representation in use (which isn't documented!). To make things worse, some FPEs (eg the ARM-Linux one) use yet another internal format... That is at least public, but it's just "different". :-( And I haven't even mentioned the VFP yet! R.