From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14347 invoked by alias); 7 Nov 2011 01:16:24 -0000 Received: (qmail 14319 invoked by uid 22791); 7 Nov 2011 01:16:20 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_NONE,TW_BJ,TW_GJ,TW_HW,TW_IW,TW_MX,TW_QE,TW_TJ,TW_VF,TW_XF X-Spam-Check-By: sourceware.org Received: from smtp02.smtpout.orange.fr (HELO smtp.smtpout.orange.fr) (80.12.242.124) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Nov 2011 01:16:05 +0000 Received: from treguer.localnet ([90.32.162.16]) by mwinf5d49 with ME id u1G21h0040MXwpW031G2TF; Mon, 07 Nov 2011 02:16:03 +0100 From: "Yann E. MORIN" To: crossgcc@sourceware.org Subject: Re: ARM-PXA toolchain Date: Mon, 07 Nov 2011 01:16:00 -0000 User-Agent: KMail/1.13.5 (Linux/3.1.0-treguer; KDE/4.4.5; x86_64; ; ) Cc: Mircea Gherzan References: <4EB6B5A3.3020100@gmail.com> <201111061755.06468.yann.morin.1998@anciens.enib.fr> <4EB6E411.5030706@gmail.com> In-Reply-To: <4EB6E411.5030706@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201111070216.01821.yann.morin.1998@anciens.enib.fr> Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00019.txt.bz2 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 YEM: above load sin r2 value at 0x17fa4, which has bit 7 unset (see below) 17f5c: e59f3044 ldr r3, [pc, #68] ; 17fa8 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 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 : 17f80: e3120c02 tst r2, #512 ; 0x200 17f84: 0a000005 beq 17fa0 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 : 17fa0: eafff80d b 15fdc <__sigjmp_save> 17fa4: 0000f098 .word 0x0000f098 YEM: 0x0000f098 has bit 7 unset. 00017fa8 : 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