* ARM-PXA toolchain
@ 2011-11-06 16:28 Mircea Gherzan
2011-11-06 16:55 ` Yann E. MORIN
0 siblings, 1 reply; 9+ messages in thread
From: Mircea Gherzan @ 2011-11-06 16:28 UTC (permalink / raw)
To: crossgcc
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: ARM-PXA toolchain 2011-11-06 16:28 ARM-PXA toolchain Mircea Gherzan @ 2011-11-06 16:55 ` Yann E. MORIN 2011-11-06 19:46 ` Mircea Gherzan 0 siblings, 1 reply; 9+ messages in thread From: Yann E. MORIN @ 2011-11-06 16:55 UTC (permalink / raw) To: crossgcc; +Cc: Mircea Gherzan 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ARM-PXA toolchain 2011-11-06 16:55 ` Yann E. MORIN @ 2011-11-06 19:46 ` Mircea Gherzan 2011-11-07 1:16 ` Yann E. MORIN 0 siblings, 1 reply; 9+ messages in thread From: Mircea Gherzan @ 2011-11-06 19:46 UTC (permalink / raw) To: Yann E. MORIN; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ARM-PXA toolchain 2011-11-06 19:46 ` Mircea Gherzan @ 2011-11-07 1:16 ` Yann E. MORIN 2011-11-08 12:23 ` Mircea Gherzan 0 siblings, 1 reply; 9+ messages in thread From: Yann E. MORIN @ 2011-11-07 1:16 UTC (permalink / raw) To: crossgcc; +Cc: Mircea Gherzan 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ARM-PXA toolchain 2011-11-07 1:16 ` Yann E. MORIN @ 2011-11-08 12:23 ` Mircea Gherzan 2011-11-08 17:19 ` Richard Earnshaw 2011-11-10 20:16 ` Yann E. MORIN 0 siblings, 2 replies; 9+ messages in thread From: Mircea Gherzan @ 2011-11-08 12:23 UTC (permalink / raw) To: Yann E. MORIN; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ARM-PXA toolchain 2011-11-08 12:23 ` Mircea Gherzan @ 2011-11-08 17:19 ` Richard Earnshaw 2011-11-08 22:37 ` Yann E. MORIN 2011-11-10 20:16 ` Yann E. MORIN 1 sibling, 1 reply; 9+ messages in thread From: Richard Earnshaw @ 2011-11-08 17:19 UTC (permalink / raw) To: Mircea Gherzan; +Cc: Yann E. MORIN, crossgcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ARM-PXA toolchain 2011-11-08 17:19 ` Richard Earnshaw @ 2011-11-08 22:37 ` Yann E. MORIN 2011-11-09 8:39 ` Mircea Gherzan 0 siblings, 1 reply; 9+ messages in thread From: Yann E. MORIN @ 2011-11-08 22:37 UTC (permalink / raw) To: Richard Earnshaw; +Cc: Mircea Gherzan, crossgcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ARM-PXA toolchain 2011-11-08 22:37 ` Yann E. MORIN @ 2011-11-09 8:39 ` Mircea Gherzan 0 siblings, 0 replies; 9+ messages in thread From: Mircea Gherzan @ 2011-11-09 8:39 UTC (permalink / raw) To: Yann E. MORIN; +Cc: Richard Earnshaw, crossgcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ARM-PXA toolchain 2011-11-08 12:23 ` Mircea Gherzan 2011-11-08 17:19 ` Richard Earnshaw @ 2011-11-10 20:16 ` Yann E. MORIN 1 sibling, 0 replies; 9+ messages in thread From: Yann E. MORIN @ 2011-11-10 20:16 UTC (permalink / raw) To: crossgcc; +Cc: Mircea Gherzan 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-11-10 20:16 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-11-06 16:28 ARM-PXA toolchain Mircea Gherzan 2011-11-06 16:55 ` Yann E. MORIN 2011-11-06 19:46 ` Mircea Gherzan 2011-11-07 1:16 ` Yann E. MORIN 2011-11-08 12:23 ` Mircea Gherzan 2011-11-08 17:19 ` Richard Earnshaw 2011-11-08 22:37 ` Yann E. MORIN 2011-11-09 8:39 ` Mircea Gherzan 2011-11-10 20:16 ` Yann E. MORIN
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).