ARM-PXA toolchain

[Mircea Gherzan]

Hi,

Am 08.11.2011 23:36, schrieb Yann E. MORIN:
> At any optimisation level,  -O{s,1,2,3}, the assembly now looks like:
>
>    00000000<my_vstmia>:
>       0:   ecac8b10        vstmia  ip!, {d8-d15}
>       4:   ecac8b10        vstmia  ip!, {d8-d15}
>       8:   e12fff1e        bx      lr
>
> So yes, the stc and the vstmia opcodes in the code snippet above are both
> encoded into the same assembly instruction. But still, it does not tell
> whether it's due to 'as' being smart, or the two opcodes actually being
> the same in that situation...

The opcodes are equal:

Bits	STC		VSTM
----	---		----
27-25	b110		b110
19-16	Rn  == IP	Rn == IP
15-12	CRd == 8	Vd == d8 == 8
11-08	coproc == 11	b1011 (A1 encoding)
07-00	64 >> 2 == 16	16 (twice the number of regs)

And this makes perfect sense since CP11 is the VFP coprocessor.

OTOH, a HelloWorld compiled with -mcpu=xscale and uClibc instead of 
eglibc runs just fine with qemu -pxa 270.

AFAICT, there's no runtime detection of VFP in uClibc. Here's the 
relevant part of libc/sysdeps/linux/arm/setjmp.S:

---8<---
#if defined __UCLIBC_HAS_FLOATS__ && ! defined __UCLIBC_HAS_SOFT_FLOAT__
# ifdef __VFP_FP__
         /* Store the VFP registers.  */
         /* Following instruction is fstmiax ip!, {d8-d15}.  */
         stc     p11, cr8, [r12], #68
         /* Store the floating-point status register.  */
         /* Following instruction is fmrx r2, fpscr.  */
         mrc     p10, 7, r2, cr1, cr0, 0
         str     r2, [ip], #4
---8<---

The first #if evaluates to FALSE because I used "ct-ng 
arm-unknown-linux-uclibcgnueabi" and the corresponding uClibc config 
file declares:

UCLIBC_HAS_FLOATS=y
# UCLIBC_HAS_FPU is not set
UCLIBC_HAS_SOFT_FLOAT=y

So now the question is: is there any (simple?) way of proving (with 
uClibc) that the VFP exposure/detection (hwcaps?) in QEMU is broken?

Thanks,
Mircea

--
For unsubscribe information see http://sourceware.org/lists.html#faq