Re: internal error reading f0-f7 registers in arm-elf targets.

[Richard Earnshaw <rearnsha 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.