This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: internal error reading f0-f7 registers in arm-elf targets.
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: amichelotti at ipitec dot it, Daniel Jacobowitz <drow at mvista dot com>, Richard Earnshaw <rearnsha at arm dot com>, gdb-patches at sources dot redhat dot com
- Date: Mon, 28 Jul 2003 09:41:21 +0100
- Subject: Re: internal error reading f0-f7 registers in arm-elf targets.
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
>
> > 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.