ARM-PXA toolchain

ARM-PXA toolchain

[Mircea Gherzan]

Hi,

I am trying to build a Xscale/PXA linux-gnueabi toolchain by setting 
CT_ARCH_ARCH to "iwmmxt" and CT_ARCH_CPU to "xscale".

When I run a trivial binary (compiled with this toolchain) in QEMU via

	qemu-arm -g 1234 -cpu pxa270 -L $PATH_TO_SYSROOT ./test

I get a SIGILL because of a VSTM instruction which is only available on 
VFPv2/3-enabled cores.

	Program received signal SIGILL, Illegal instruction.
	0x40818f24 in ?? ()
	(gdb) disp/i $pc
	1: x/i $pc
	=> 0x40818f24:  vstmia  r12!, {d8-d15}

AFAIK, PXA chips have iwMMXt but no VFP. Since my test binary is just a 
main() with a "return 0", the problem should be in the ld-linux loader.

How should I configure ct-ng for a proper toolchain for PXA (i.e. 
without any VFP instructions in the libraries/loader)?

Thanks,
Mircea

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

Re: ARM-PXA toolchain

[Yann E. MORIN]

Mircea, All,

On Sunday 06 November 2011 17:28:19 Mircea Gherzan wrote:
> I am trying to build a Xscale/PXA linux-gnueabi toolchain by setting 
> CT_ARCH_ARCH to "iwmmxt" and CT_ARCH_CPU to "xscale".
> 
> When I run a trivial binary (compiled with this toolchain) in QEMU via
> 	qemu-arm -g 1234 -cpu pxa270 -L $PATH_TO_SYSROOT ./test

AFAIK, pxa2xx do not have iwmmxt. iwmmxt is present only on pxa3xx and
above.

> I get a SIGILL because of a VSTM instruction which is only available on 
> VFPv2/3-enabled cores.
> 	Program received signal SIGILL, Illegal instruction.
> 	0x40818f24 in ?? ()
> 	(gdb) disp/i $pc
> 	1: x/i $pc
> 	=> 0x40818f24:  vstmia  r12!, {d8-d15}

Looks like you are building with hardware floating point, and your
kernel does not have FP emulation.

> AFAIK, PXA chips have iwMMXt but no VFP. Since my test binary is just a 
> main() with a "return 0", the problem should be in the ld-linux loader.
> 
> How should I configure ct-ng for a proper toolchain for PXA (i.e. 
> without any VFP instructions in the libraries/loader)?

The bundled sample arm-unknown-linux-uclibcgnueabi is configured for
pxa25 (and it worked great on my pxa255 at the time I needed it):

  ct-ng arm-unknown-linux-uclibcgnueabi
  ct-ng build

Here are the related configuration items:
  CT_ARCH_ARCH="armv5te"
  CT_ARCH_CPU="xscale"
  CT_ARCH_TUNE="xscale"
  CT_ARCH_FPU=""
  CT_ARCH_FLOAT_SW=y

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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

Re: ARM-PXA toolchain

[Mircea Gherzan]

Hi,

Am 06.11.2011 17:55, schrieb Yann E. MORIN:
> Looks like you are building with hardware floating point, and your
> kernel does not have FP emulation.

No, I was not building with hard FP. It's a qemu-user environment, 
therefore the lack of FP emulation.

> Here are the related configuration items:
>    CT_ARCH_ARCH="armv5te"
>    CT_ARCH_CPU="xscale"
>    CT_ARCH_TUNE="xscale"
>    CT_ARCH_FPU=""
>    CT_ARCH_FLOAT_SW=y

I've tried this [1] but the ld-linux.so.3 still contains some VFP 
instructions (objdump | grep vstm):

  17f44:       	ecac8b10        vstmia  	ip!, {d8-d15}
  538:   	4d2f4a16        vstmdbmi        pc!, {s8-s29}

Regards,
Mircea

[1] http://pastebin.com/ky7Dxp3C

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

Re: ARM-PXA toolchain

[Yann E. MORIN]

Mircea, All,

On Sunday 06 November 2011 20:46:25 Mircea Gherzan wrote:
> Am 06.11.2011 17:55, schrieb Yann E. MORIN:
> > Looks like you are building with hardware floating point, and your
> > kernel does not have FP emulation.
> 
> No, I was not building with hard FP.

OK.

> > Here are the related configuration items:
> >    CT_ARCH_ARCH="armv5te"
> >    CT_ARCH_CPU="xscale"
> >    CT_ARCH_TUNE="xscale"
> >    CT_ARCH_FPU=""
> >    CT_ARCH_FLOAT_SW=y
> 
> I've tried this [1] but the ld-linux.so.3 still contains some VFP 
> instructions (objdump | grep vstm):
> 
>   17f44:       	ecac8b10        vstmia  	ip!, {d8-d15}
>   538:   	4d2f4a16        vstmdbmi        pc!, {s8-s29}
> [1] http://pastebin.com/ky7Dxp3C

I've tried your .config, and get only one VFP instruction:

$ arm-unknown-linux-guneabi-objdump -d ld-linux.so.3 |grep vst
   17f74:       ecac8b10        vstmia  ip!, {d8-d15}

Looking at the dump, it is in the sigsetjmp function:

---8<---
00017f50 <__GI___sigsetjmp>:
   17f50:       e1a0c000        mov     ip, r0
   17f54:       e8ac6ff0        stmia   ip!, {r4, r5, r6, r7, r8, r9, sl, fp, sp, lr}
   17f58:       e59f2044        ldr     r2, [pc, #68]   ; 17fa4 <Lno_iwmmxt+0x4>
YEM: above load sin r2 value at 0x17fa4, which has bit 7 unset (see below)
   17f5c:       e59f3044        ldr     r3, [pc, #68]   ; 17fa8 <Lrtld_local_ro>
   17f60:       e08f2002        add     r2, pc, r2
   17f64:       e0822003        add     r2, r2, r3
   17f68:       e5922040        ldr     r2, [r2, #64]   ; 0x40
   17f6c:       e3120040        tst     r2, #64 ; 0x40
YEM: Alas, r2 is now spoiled with pc and r3, so 
   17f70:       0a000002        beq     17f80 <Lno_vfp>
YEM: the insn above should jmp to Lno_vfp if your CPU does not have VFP
YEM: so the following vstmia should not happen:
   17f74:       ecac8b10        vstmia  ip!, {d8-d15}
   17f78:       eef13a10        vmrs    r3, fpscr
   17f7c:       e48c3004        str     r3, [ip], #4

00017f80 <Lno_vfp>:
   17f80:       e3120c02        tst     r2, #512        ; 0x200
   17f84:       0a000005        beq     17fa0 <Lno_iwmmxt>
YEM: ditto here for iwmmxt
   17f88:       ececa102        stfp    f2, [ip], #8
   17f8c:       ececb102        stfp    f3, [ip], #8
   17f90:       ececc102        stfp    f4, [ip], #8
   17f94:       ececd102        stfp    f5, [ip], #8
   17f98:       ecece102        stfp    f6, [ip], #8
   17f9c:       ececf102        stfp    f7, [ip], #8

00017fa0 <Lno_iwmmxt>:
   17fa0:       eafff80d        b       15fdc <__sigjmp_save>
   17fa4:       0000f098        .word   0x0000f098
YEM: 0x0000f098 has bit 7 unset.

00017fa8 <Lrtld_local_ro>:
   17fa8:       fffffdc8        .word   0xfffffdc8
   17fac:       e1a00000        .word   0xe1a00000
---8<---

The source file is: ports/sysdeps/arm/eabi/setjmp.S
Here's the code (lines starting with 'YEM' are my comments):

---8<---
ENTRY (__sigsetjmp)
        mov     ip, r0

        /* Save registers */
        stmia   ip!, {v1-v6, sl, fp, sp, lr}

        /* Check if we have a VFP unit.  */
#ifdef IS_IN_rtld
        ldr     a3, 1f
        ldr     a4, Lrtld_local_ro
0:      add     a3, pc, a3
        add     a3, a3, a4
        ldr     a3, [a3, #RTLD_GLOBAL_RO_DL_HWCAP_OFFSET]
#else
#ifdef PIC
        ldr     a3, 1f
        ldr     a4, Lrtld_global_ro
0:      add     a3, pc, a3
        ldr     a3, [a3, a4]
        ldr     a3, [a3, #RTLD_GLOBAL_RO_DL_HWCAP_OFFSET]
#else
        ldr     a3, Lhwcap
        ldr     a3, [a3, #0]
#endif
#endif
        tst     a3, #HWCAP_ARM_VFP
        beq     Lno_vfp

YEM: pay attention to the following comment!
        /* Store the VFP registers.
           Don't use VFP instructions directly because this code
           is used in non-VFP multilibs.  */
        /* Following instruction is vstmia ip!, {d8-d15}.  */
        stc     p11, cr8, [ip], #64
YEM: Aha! The instruction above *is* vstmia!
        /* Store the floating-point status register.  */
        /* Following instruction is vmrs a4, fpscr.  */
        mrc     p10, 7, a4, cr1, cr0, 0
YEM: See also how the above is in fact vmrs
        str     a4, [ip], #4
Lno_vfp:

        tst     a3, #HWCAP_ARM_IWMMXT
        beq     Lno_iwmmxt

        /* Save the call-preserved iWMMXt registers.  */
        /* Following instructions are wstrd wr10, [ip], #8 (etc.)  */
        stcl    p1, cr10, [r12], #8
        stcl    p1, cr11, [r12], #8
        stcl    p1, cr12, [r12], #8
        stcl    p1, cr13, [r12], #8
        stcl    p1, cr14, [r12], #8
        stcl    p1, cr15, [r12], #8
Lno_iwmmxt:

        /* Make a tail call to __sigjmp_save; it takes the same args.  */
        B       PLTJMP(C_SYMBOL_NAME(__sigjmp_save))

#ifdef IS_IN_rtld
1:      .long   _GLOBAL_OFFSET_TABLE_ - 0b - 8
Lrtld_local_ro:
        .long   C_SYMBOL_NAME(_rtld_local_ro)(GOTOFF)
#else
#ifdef PIC
1:      .long   _GLOBAL_OFFSET_TABLE_ - 0b - 8
Lrtld_global_ro:
        .long   C_SYMBOL_NAME(_rtld_global_ro)(GOT)
#else
Lhwcap:
        .long   C_SYMBOL_NAME(_dl_hwcap)
#endif
#endif

END (__sigsetjmp)
---8<---

OK, so why is the 'stc' instruction shown as being 'vstmia'?
There are two probable reasons:
 - 'as' tries to be smart, and notices that the 'stc' is in fact an 'stmia'
   so it translates that 'stc' to the (faster?) 'vstmia'
 - this specific 'stc' and 'vstmia' are coded the same, so 'objdump' gets
   confused, and decodes the insn as being 'vstmia'

Notice however, that the vstmia should not be executed on a CPU that does
not have a VFP (see the test above).

So, maybe qemu-user improperly handles that situation, not emulating VFP,
but exposing its presence.

So, here's my line of thought:
 - the code is assembly, so gcc is not at fault in any way
   --> 99% sure
 - there is an issue in binutils, with as smartery and/or objdump confusion
   --> probably not
 - eglibc-2.14 can't run on no-VFP CPU
   --> probably not
 - qemu-user mis-behaves
   --> probably

Did you try on real hardware?

BTW, here is the full list of libraries with vstmia in them:
---- arm-462-linux-gnueabi/arm-462-linux-gnueabi/sysroot/lib/ld-2.14.1.so
   17f74:       ecac8b10        vstmia  ip!, {d8-d15}
---- arm-462-linux-gnueabi/arm-462-linux-gnueabi/sysroot/lib/libanl-2.14.1.so
    2874:       ec800b20        vstmia  r0, {d0-d15}
    2884:       ecc00b20        vstmia  r0, {d16-d31}
---- arm-462-linux-gnueabi/arm-462-linux-gnueabi/sysroot/lib/libc-2.14.1.so
   2cbd4:       ecac8b10        vstmia  ip!, {d8-d15}
---- arm-462-linux-gnueabi/arm-462-linux-gnueabi/sysroot/usr/lib/libanl.so
    2874:       ec800b20        vstmia  r0, {d0-d15}
    2884:       ecc00b20        vstmia  r0, {d16-d31}

What's interesting is that in libc, vstmia is also in sigsetjmp.
Also, there are vldmia in longjmp.

Sorry, I can't help much more here... :-/

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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

Re: ARM-PXA toolchain

[Mircea Gherzan]

Hi, 

First of all thanks for your thorough analysis!

On Mon, Nov 07, 2011 at 02:16:01AM +0100, Yann E. MORIN wrote:
> The source file is: ports/sysdeps/arm/eabi/setjmp.S
> Here's the code (lines starting with 'YEM' are my comments):
> 
> ---8<---
> ENTRY (__sigsetjmp)
>         mov     ip, r0
> 
>         /* Save registers */
>         stmia   ip!, {v1-v6, sl, fp, sp, lr}
> 
>         /* Check if we have a VFP unit.  */
> #ifdef IS_IN_rtld
>         ldr     a3, 1f
>         ldr     a4, Lrtld_local_ro
> 0:      add     a3, pc, a3
>         add     a3, a3, a4
>         ldr     a3, [a3, #RTLD_GLOBAL_RO_DL_HWCAP_OFFSET]
> #else
> #ifdef PIC
>         ldr     a3, 1f
>         ldr     a4, Lrtld_global_ro
> 0:      add     a3, pc, a3
>         ldr     a3, [a3, a4]
>         ldr     a3, [a3, #RTLD_GLOBAL_RO_DL_HWCAP_OFFSET]
> #else
>         ldr     a3, Lhwcap
>         ldr     a3, [a3, #0]
> #endif
> #endif
>         tst     a3, #HWCAP_ARM_VFP
>         beq     Lno_vfp
> 
> YEM: pay attention to the following comment!
>         /* Store the VFP registers.
>            Don't use VFP instructions directly because this code
>            is used in non-VFP multilibs.  */
>         /* Following instruction is vstmia ip!, {d8-d15}.  */
>         stc     p11, cr8, [ip], #64
> YEM: Aha! The instruction above *is* vstmia!
>         /* Store the floating-point status register.  */
>         /* Following instruction is vmrs a4, fpscr.  */
>         mrc     p10, 7, a4, cr1, cr0, 0
> YEM: See also how the above is in fact vmrs
>         str     a4, [ip], #4
> Lno_vfp:
> 
>         tst     a3, #HWCAP_ARM_IWMMXT
>         beq     Lno_iwmmxt
> 
>         /* Save the call-preserved iWMMXt registers.  */
>         /* Following instructions are wstrd wr10, [ip], #8 (etc.)  */
>         stcl    p1, cr10, [r12], #8
>         stcl    p1, cr11, [r12], #8
>         stcl    p1, cr12, [r12], #8
>         stcl    p1, cr13, [r12], #8
>         stcl    p1, cr14, [r12], #8
>         stcl    p1, cr15, [r12], #8
> Lno_iwmmxt:
> 
>         /* Make a tail call to __sigjmp_save; it takes the same args.  */
>         B       PLTJMP(C_SYMBOL_NAME(__sigjmp_save))
> 
> #ifdef IS_IN_rtld
> 1:      .long   _GLOBAL_OFFSET_TABLE_ - 0b - 8
> Lrtld_local_ro:
>         .long   C_SYMBOL_NAME(_rtld_local_ro)(GOTOFF)
> #else
> #ifdef PIC
> 1:      .long   _GLOBAL_OFFSET_TABLE_ - 0b - 8
> Lrtld_global_ro:
>         .long   C_SYMBOL_NAME(_rtld_global_ro)(GOT)
> #else
> Lhwcap:
>         .long   C_SYMBOL_NAME(_dl_hwcap)
> #endif
> #endif
> 
> END (__sigsetjmp)
> ---8<---
> 
> OK, so why is the 'stc' instruction shown as being 'vstmia'?
> There are two probable reasons:
>  - 'as' tries to be smart, and notices that the 'stc' is in fact an 'stmia'
>    so it translates that 'stc' to the (faster?) 'vstmia'
>  - this specific 'stc' and 'vstmia' are coded the same, so 'objdump' gets
>    confused, and decodes the insn as being 'vstmia'

I can't check the coding for I can't compile a simple:

	void my_vstmia(void)
	{
    		__asm__("stc     p11, cr8, [ip], #64");
    		__asm__("vstmia  ip!, {d8 - d51}");
	}

With -march=armv7-a -mcpu=cortex-a9 -mfpu=vfpv3-d16 -mhard-float I get:

  "VFP single precision register expected -- `vstmia ip!,{d8-d51}'"

With -march=armv7-a -mcpu=cortex-a9 -mfpu=vfpv3-d16 -msoft-float I get:
  	
  "selected processor does not support ARM mode `vstmia ip!,{d8-d51}'"

> Notice however, that the vstmia should not be executed on a CPU that does
> not have a VFP (see the test above).
> 
> So, maybe qemu-user improperly handles that situation, not emulating VFP,
> but exposing its presence.

Qemu is also my guess. I've filed a bug report [1].

> Did you try on real hardware?

No, I don't have it.

Thanks,
Mircea

[1] https://bugs.launchpad.net/qemu/+bug/887516

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

Re: ARM-PXA toolchain

[Richard Earnshaw]

On 08/11/11 12:23, Mircea Gherzan wrote:
> Hi, 
> 
> First of all thanks for your thorough analysis!
> 
> On Mon, Nov 07, 2011 at 02:16:01AM +0100, Yann E. MORIN wrote:
>> The source file is: ports/sysdeps/arm/eabi/setjmp.S
>> Here's the code (lines starting with 'YEM' are my comments):
>>
>> ---8<---
>> ENTRY (__sigsetjmp)
>>         mov     ip, r0
>>
>>         /* Save registers */
>>         stmia   ip!, {v1-v6, sl, fp, sp, lr}
>>
>>         /* Check if we have a VFP unit.  */
>> #ifdef IS_IN_rtld
>>         ldr     a3, 1f
>>         ldr     a4, Lrtld_local_ro
>> 0:      add     a3, pc, a3
>>         add     a3, a3, a4
>>         ldr     a3, [a3, #RTLD_GLOBAL_RO_DL_HWCAP_OFFSET]
>> #else
>> #ifdef PIC
>>         ldr     a3, 1f
>>         ldr     a4, Lrtld_global_ro
>> 0:      add     a3, pc, a3
>>         ldr     a3, [a3, a4]
>>         ldr     a3, [a3, #RTLD_GLOBAL_RO_DL_HWCAP_OFFSET]
>> #else
>>         ldr     a3, Lhwcap
>>         ldr     a3, [a3, #0]
>> #endif
>> #endif
>>         tst     a3, #HWCAP_ARM_VFP
>>         beq     Lno_vfp
>>
>> YEM: pay attention to the following comment!
>>         /* Store the VFP registers.
>>            Don't use VFP instructions directly because this code
>>            is used in non-VFP multilibs.  */
>>         /* Following instruction is vstmia ip!, {d8-d15}.  */
>>         stc     p11, cr8, [ip], #64
>> YEM: Aha! The instruction above *is* vstmia!
>>         /* Store the floating-point status register.  */
>>         /* Following instruction is vmrs a4, fpscr.  */
>>         mrc     p10, 7, a4, cr1, cr0, 0
>> YEM: See also how the above is in fact vmrs
>>         str     a4, [ip], #4
>> Lno_vfp:
>>
>>         tst     a3, #HWCAP_ARM_IWMMXT
>>         beq     Lno_iwmmxt
>>
>>         /* Save the call-preserved iWMMXt registers.  */
>>         /* Following instructions are wstrd wr10, [ip], #8 (etc.)  */
>>         stcl    p1, cr10, [r12], #8
>>         stcl    p1, cr11, [r12], #8
>>         stcl    p1, cr12, [r12], #8
>>         stcl    p1, cr13, [r12], #8
>>         stcl    p1, cr14, [r12], #8
>>         stcl    p1, cr15, [r12], #8
>> Lno_iwmmxt:
>>
>>         /* Make a tail call to __sigjmp_save; it takes the same args.  */
>>         B       PLTJMP(C_SYMBOL_NAME(__sigjmp_save))
>>
>> #ifdef IS_IN_rtld
>> 1:      .long   _GLOBAL_OFFSET_TABLE_ - 0b - 8
>> Lrtld_local_ro:
>>         .long   C_SYMBOL_NAME(_rtld_local_ro)(GOTOFF)
>> #else
>> #ifdef PIC
>> 1:      .long   _GLOBAL_OFFSET_TABLE_ - 0b - 8
>> Lrtld_global_ro:
>>         .long   C_SYMBOL_NAME(_rtld_global_ro)(GOT)
>> #else
>> Lhwcap:
>>         .long   C_SYMBOL_NAME(_dl_hwcap)
>> #endif
>> #endif
>>
>> END (__sigsetjmp)
>> ---8<---
>>
>> OK, so why is the 'stc' instruction shown as being 'vstmia'?
>> There are two probable reasons:
>>  - 'as' tries to be smart, and notices that the 'stc' is in fact an 'stmia'
>>    so it translates that 'stc' to the (faster?) 'vstmia'
>>  - this specific 'stc' and 'vstmia' are coded the same, so 'objdump' gets
>>    confused, and decodes the insn as being 'vstmia'
> 
> I can't check the coding for I can't compile a simple:
> 
> 	void my_vstmia(void)
> 	{
>     		__asm__("stc     p11, cr8, [ip], #64");
>     		__asm__("vstmia  ip!, {d8 - d51}");
> 	}
> 

That's a heck of a lot of double-precision registers!  Perhaps you meant
D15, not D51.

R.


> With -march=armv7-a -mcpu=cortex-a9 -mfpu=vfpv3-d16 -mhard-float I get:
> 
>   "VFP single precision register expected -- `vstmia ip!,{d8-d51}'"
> 
> With -march=armv7-a -mcpu=cortex-a9 -mfpu=vfpv3-d16 -msoft-float I get:
>   	
>   "selected processor does not support ARM mode `vstmia ip!,{d8-d51}'"
> 
>> Notice however, that the vstmia should not be executed on a CPU that does
>> not have a VFP (see the test above).
>>
>> So, maybe qemu-user improperly handles that situation, not emulating VFP,
>> but exposing its presence.
> 
> Qemu is also my guess. I've filed a bug report [1].
> 
>> Did you try on real hardware?
> 
> No, I don't have it.
> 
> Thanks,
> Mircea
> 
> [1] https://bugs.launchpad.net/qemu/+bug/887516
> 
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
> 
> 
> 



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

Re: ARM-PXA toolchain

[Yann E. MORIN]

Mircea, Richard, All,

On Tuesday 08 November 2011 18:18:49 Richard Earnshaw wrote:
> On 08/11/11 12:23, Mircea Gherzan wrote:
> > I can't check the coding for I can't compile a simple:
> > 	void my_vstmia(void)
> > 	{
> >     		__asm__("stc     p11, cr8, [ip], #64");
> >     		__asm__("vstmia  ip!, {d8 - d51}");
> > 	}
> 
> That's a heck of a lot of double-precision registers!  Perhaps you meant
> D15, not D51.

Aha! Good catch! :-)

Compiled with Mircea's original toolchain settings, and changing 'd51'
to 'd15' as spotted by Richard, I was able to compile that code snippet
(notice however the -O0 to not optimise at all):

  $ arm-unknown-linux-gnueabi-gcc -march=armv7-a -mcpu=cortex-a9 \
                                  -mfpu=vfpv3-d16 -mhard-float   \
                                  -O0 -o ess.o -c ess.c
  $ arm-unknown-linux-gnueabi-objdump -d ess.o
[--SNIP--]
  00000000 <my_vstmia>:
     0: e52db004        push    {fp}            ; (str fp, [sp, #-4]!)
     4: e28db000        add     fp, sp, #0
     8: ecac8b10        vstmia  ip!, {d8-d15}
     c: ecac8b10        vstmia  ip!, {d8-d15}
    10: e28bd000        add     sp, fp, #0
    14: e8bd0800        pop     {fp}
    18: e12fff1e        bx      lr

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...

Anyway, I would highly be surprised that eglibc would not run on non-VFP
hardware at all. So definitely, it looks (to me) like a bug in QEMU.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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

Re: 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

Re: ARM-PXA toolchain

[Yann E. MORIN]

Mircea, All,

On Tuesday 08 November 2011 13:23:07 Mircea Gherzan wrote:
> Qemu is also my guess. I've filed a bug report [1].
> [1] https://bugs.launchpad.net/qemu/+bug/887516

For the records, this was indeed a QEMU bug, which is now fixed:
    http://lists.nongnu.org/archive/html/qemu-devel/2011-11/msg01242.html

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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