Re: is ARMv4T deprecated?
On Fri, Apr 17, 2015 at 11:36:13PM +0200, Bernhard Reutner-Fischer wrote: > On April 17, 2015 8:54:06 PM GMT+02:00, Sergiy Kibrik wrote: > >On 4/17/15 6:59 PM, Bernhard Reutner-Fischer wrote: > >> On 17 April 2015 at 14:32, Bernhard Reutner-Fischer > >> wrote: > >> > >>> So i read some documents yesterday night and this lead me to think > >>> that the condition is just inverted? > >>> Shouldn't it read more like: > >> > >> May i ask you to try the attached on your arm920t, please? > >> > >> This should of course be tested in pure ARM mode too.. > >> > > > >sure. It seems to be working fine on arm920t in both thumb-interwork & > >arm-only modes (however I can't try on other hardware currently). > > Excellent, thanks a lot for testing! I've pushed this now. Thanks, again, for your help! cheers, ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On April 17, 2015 8:54:06 PM GMT+02:00, Sergiy Kibrik wrote: >On 4/17/15 6:59 PM, Bernhard Reutner-Fischer wrote: >> On 17 April 2015 at 14:32, Bernhard Reutner-Fischer >> wrote: >> >>> So i read some documents yesterday night and this lead me to think >>> that the condition is just inverted? >>> Shouldn't it read more like: >> >> May i ask you to try the attached on your arm920t, please? >> >> This should of course be tested in pure ARM mode too.. >> > >sure. It seems to be working fine on arm920t in both thumb-interwork & >arm-only modes (however I can't try on other hardware currently). Excellent, thanks a lot for testing! Cheers, ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On 4/17/15 6:59 PM, Bernhard Reutner-Fischer wrote: > On 17 April 2015 at 14:32, Bernhard Reutner-Fischer > wrote: > >> So i read some documents yesterday night and this lead me to think >> that the condition is just inverted? >> Shouldn't it read more like: > > May i ask you to try the attached on your arm920t, please? > > This should of course be tested in pure ARM mode too.. > sure. It seems to be working fine on arm920t in both thumb-interwork & arm-only modes (however I can't try on other hardware currently). -- regards, Sergey signature.asc Description: OpenPGP digital signature ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On 17 April 2015 at 14:32, Bernhard Reutner-Fischer
wrote:
> So i read some documents yesterday night and this lead me to think
> that the condition is just inverted?
> Shouldn't it read more like:
May i ask you to try the attached on your arm920t, please?
This should of course be tested in pure ARM mode too..
TIA && cheers,
diff --git a/include/libc-symbols.h b/include/libc-symbols.h
index a87cde6..97463ac 100644
--- a/include/libc-symbols.h
+++ b/include/libc-symbols.h
@@ -111,7 +111,7 @@
/* Indirect stringification. Doing two levels allows
* the parameter to be a macro itself.
*/
-#define __stringify_1(x)#x
+#define __stringify_1(x...)#x
#define __stringify(x) __stringify_1(x)
#ifdef __UCLIBC_HAVE_ASM_SET_DIRECTIVE__
diff --git a/ldso/ldso/arm/dl-startup.h b/ldso/ldso/arm/dl-startup.h
index df2c824..eb2a9a2 100644
--- a/ldso/ldso/arm/dl-startup.h
+++ b/ldso/ldso/arm/dl-startup.h
@@ -47,11 +47,7 @@ __asm__(
" ldr r0, .L_FINI_PROC\n"
" ldr r0, [sl, r0]\n"
" @ jump to the user_s entry point\n"
-#if defined(__USE_BX__)
- " bx r6\n"
-#else
- " mov pc, r6\n"
-#endif
+ " " __stringify(BX(r6)) "\n"
".L_GET_GOT:\n"
" .word _GLOBAL_OFFSET_TABLE_ - .L_GOT_GOT - 4\n"
".L_SKIP_ARGS:\n"
@@ -113,11 +109,7 @@ __asm__(
" ldr r0, .L_FINI_PROC\n"
" ldr r0, [r7, r0]\n"
" @ jump to the user_s entry point\n"
-#if defined(__USE_BX__)
- " bx r6\n"
-#else
- " mov pc, r6\n"
-#endif
+ " " __stringify(BX(r6)) "\n"
"\n\n"
".L_GET_GOT:\n"
" .word _GLOBAL_OFFSET_TABLE_ - .L_GOT_GOT - 4\n"
diff --git a/ldso/ldso/arm/resolve.S b/ldso/ldso/arm/resolve.S
index c1caf9a..7e0058e 100644
--- a/ldso/ldso/arm/resolve.S
+++ b/ldso/ldso/arm/resolve.S
@@ -90,12 +90,10 @@
* dl-startup.c).
*/
-#include
+#include
#include
#include
-#include
-
#define sl r10
#define fp r11
#define ip r12
@@ -114,8 +112,8 @@ _dl_linux_resolve:
@ function must branch to the real function, and that expects
@ r0-r3 and lr to be as they were before the whole PLT stuff -
@ ip can be trashed.
- @ This routine is called after pushing lr, so we must push an odd
- @ number of words to keep the stack correctly aligned.
+ @ This routine is called after pushing lr, so we must push an odd
+ @ number of words to keep the stack correctly aligned.
stmdb sp!, {r0, r1, r2, r3, r4}
ldr r0, [lr, #-4] @ r0 := [lr-4] (GOT_TABLE[1])
@@ -124,16 +122,12 @@ _dl_linux_resolve:
@ ~x = -x-1, therefore ~(r1>>2) = (-((lr-ip)>>2)-1)
@ = - ((lr-ip)/4) - 1 = (ip - lr - 4)/4, as required
- bl _dl_linux_resolver
+bl _dl_linux_resolver
- mov ip, r0
+mov ip, r0
ldmia sp!, {r0, r1, r2, r3, r4, lr}
-#if defined(__USE_BX__)
- bx ip
-#else
- mov pc,ip
-#endif
+BX(ip)
#else
@ In the thumb case _dl_linux_resolver is thumb. If a bl is used
@ from arm code the linker will insert a stub call which, with
diff --git a/libc/string/arm/_memcpy.S b/libc/string/arm/_memcpy.S
index c59f5b8..2999e8e 100644
--- a/libc/string/arm/_memcpy.S
+++ b/libc/string/arm/_memcpy.S
@@ -111,11 +111,7 @@ _memcpy:
bcc .Lmemcpy_backwards
IT(t, eq) /* Quick abort for src=dst */
-#if defined(__USE_BX__)
-bxeqlr
-#else
-moveq pc, lr
-#endif
+ BXC(eq, lr)
stmdb sp!, {r0, lr} /* memcpy() returns dest addr */
subs r2, r2, #4
blt .Lmemcpy_fl4 /* less than 4 bytes */
@@ -455,11 +451,7 @@ _memcpy:
/* less than 4 bytes to go */
adds r2, r2, #4
IT(t, eq)
-#if defined(__USE_BX__)
-bxeqlr
-#else
- moveq pc, lr /* done */
-#endif
+ BXC(eq, lr) /* done */
/* copy the crud byte at a time */
cmp r2, #2
ldrb r3, [r1, #-1]!
@@ -477,11 +469,7 @@ _memcpy:
ldrgtb r3, [r1, #-1]!
strgtb r3, [r0, #-1]!
#endif
-#if defined(__USE_BX__)
-bx lr
-#else
- mov pc, lr
-#endif
+ BX(lr)
/* erg - unaligned destination */
.Lmemcpy_bdestul:
cmp r12, #2
diff --git a/libc/string/arm/memcmp.S b/libc/string/arm/memcmp.S
index 9f78415..5b9473c 100644
--- a/libc/string/arm/memcmp.S
+++ b/libc/string/arm/memcmp.S
@@ -67,11 +67,7 @@ memcmp:
subs r2, r2, #1
IT(tt, mi)
movmi r0, #0
-#if defined(__USE_BX__)
-bxmilr
-#else
- movmi pc, lr
-#endif
+ BXC(mi, lr)
/* ip == last src address to compare */
add ip, r0, r2
1:
@@ -82,11 +78,7 @@ memcmp:
cmpcs r2, r3
beq 1b
sub r0, r2, r3
-#if defined(__USE_BX__)
-bx lr
-#else
- mov pc, lr
-#endif
+ BX(lr)
#endif
.size memcmp,.-memcmp
diff --git a/libc/string/arm/memset.S b/libc/string/arm/memset.S
index 8ddc47e..2be4850 100644
--- a/libc/string/arm/memset.S
+++ b/libc/string/arm/memset.S
@@ -17,7 +17,6 @@
Re: is ARMv4T deprecated?
>>--- a/libc/sysdeps/linux/arm/bits/arm_asm.h
>>+++ b/libc/sysdeps/linux/arm/bits/arm_asm.h
>>@@ -13,12 +13,8 @@
>>unified assembly syntax. */
>> #define IT(t, cond)
>> /* Code to return from a thumb function stub. */
>>-#ifdef __ARM_ARCH_4T__
>>-#define POP_RET pop {r2, pc}
>>-#else
>> #define POP_RET pop {r2, r3}; bxr3
>> #endif
>>-#endif
>>
>> #if defined(__ARM_ARCH_6M__)
>> /* Force arm mode to flush out errors on M profile cores. */
>>
>>
>>What do you think of such fix?
>
> Should probably take USE_BX into account..
> Other than that and a signed-off-by sure, whatever works for you!
So i read some documents yesterday night and this lead me to think
that the condition is just inverted?
Shouldn't it read more like:
/* Code to return from a thumb function stub. */
#if defined __ARM_ARCH_4T__ /* && defined __THUMB_INTERWORK__ */
# define POP_RET pop {r2, r3}; bxr3
#else
# define POP_RET pop {r2, pc}
#endif
thanks,
>
> Many TIA,
>
>
___
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On April 16, 2015 9:04:47 PM GMT+02:00, Sergiy Kibrik wrote:
>On 4/16/15 12:43 AM, Bernhard Reutner-Fischer wrote:
>> Please send me your
>> grep "memcpy\.o[sS]* " log.do_compile
>> The file should be somewhere around your
>>
>tmp-uclibc/work/armv4t-oe-linux-uclibceabi/uclibc/0.9.33+gitAUTOINC+*/temp/log.do_compile
>>> >
>>> > here it goes: http://pastebin.com/VGqf31ac
>> arm-poky-linux-uclibceabi-gcc -march=armv4t -marm -mthumb-interwork
>> -msoft-float -mlittle-endian -mthumb
>>
>> I see no notion of a tune?
>>
>> IIRC armv4t defaulted to arm7TDMI. Given that OE usually does not
>> configure for a default CPU (AFAICS) you have to pass a proper tune.
>>
>> My 920t build used:
>> arm-oe-linux-uclibceabi-gcc -march=armv4t -mthumb -mthumb-interwork
>> -O2 -mtune=arm920t
>>
>> in your local.conf, try:
>> FULL_OPTIMIZATION = "-O2 -mtune=arm920t"
>> ARM_INSTRUCTION_SET := "thumb"
>>
>> maybe you need some additional settings like DEFAULTTUNE TUNE_ARCH
>> TUNE_PKGARCH that you certainly use already.
>>
>
>I tried -mtune=arm920t some time ago once, but it didn't help.
>
>I changed return [from Thumb routine] code, and it did the trick, now
>busybox and couple of utilities seems to be working (yet I didn't run
>uclibc tests):
>
>diff --git a/libc/sysdeps/linux/arm/bits/arm_asm.h
>b/libc/sysdeps/linux/arm/bits/arm_asm.h
>index 04664b3..78dc6f0 100644
>--- a/libc/sysdeps/linux/arm/bits/arm_asm.h
>+++ b/libc/sysdeps/linux/arm/bits/arm_asm.h
>@@ -13,12 +13,8 @@
>unified assembly syntax. */
> #define IT(t, cond)
> /* Code to return from a thumb function stub. */
>-#ifdef __ARM_ARCH_4T__
>-#define POP_RET pop {r2, pc}
>-#else
> #define POP_RET pop {r2, r3}; bxr3
> #endif
>-#endif
>
> #if defined(__ARM_ARCH_6M__)
> /* Force arm mode to flush out errors on M profile cores. */
>
>
>What do you think of such fix?
Should probably take USE_BX into account..
Other than that and a signed-off-by sure, whatever works for you!
Many TIA,
___
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On 4/16/15 12:43 AM, Bernhard Reutner-Fischer wrote:
>>> >> Please send me your
>>> >> grep "memcpy\.o[sS]* " log.do_compile
>>> >> The file should be somewhere around your
>>> >> tmp-uclibc/work/armv4t-oe-linux-uclibceabi/uclibc/0.9.33+gitAUTOINC+*/temp/log.do_compile
>> >
>> > here it goes: http://pastebin.com/VGqf31ac
> arm-poky-linux-uclibceabi-gcc -march=armv4t -marm -mthumb-interwork
> -msoft-float -mlittle-endian -mthumb
>
> I see no notion of a tune?
>
> IIRC armv4t defaulted to arm7TDMI. Given that OE usually does not
> configure for a default CPU (AFAICS) you have to pass a proper tune.
>
> My 920t build used:
> arm-oe-linux-uclibceabi-gcc -march=armv4t -mthumb -mthumb-interwork
> -O2 -mtune=arm920t
>
> in your local.conf, try:
> FULL_OPTIMIZATION = "-O2 -mtune=arm920t"
> ARM_INSTRUCTION_SET := "thumb"
>
> maybe you need some additional settings like DEFAULTTUNE TUNE_ARCH
> TUNE_PKGARCH that you certainly use already.
>
I tried -mtune=arm920t some time ago once, but it didn't help.
I changed return [from Thumb routine] code, and it did the trick, now
busybox and couple of utilities seems to be working (yet I didn't run
uclibc tests):
diff --git a/libc/sysdeps/linux/arm/bits/arm_asm.h
b/libc/sysdeps/linux/arm/bits/arm_asm.h
index 04664b3..78dc6f0 100644
--- a/libc/sysdeps/linux/arm/bits/arm_asm.h
+++ b/libc/sysdeps/linux/arm/bits/arm_asm.h
@@ -13,12 +13,8 @@
unified assembly syntax. */
#define IT(t, cond)
/* Code to return from a thumb function stub. */
-#ifdef __ARM_ARCH_4T__
-#define POP_RET pop{r2, pc}
-#else
#define POP_RET pop{r2, r3}; bxr3
#endif
-#endif
#if defined(__ARM_ARCH_6M__)
/* Force arm mode to flush out errors on M profile cores. */
What do you think of such fix?
--
regards,
Sergey
signature.asc
Description: OpenPGP digital signature
___
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On 16 April 2015 at 00:33, Gustavo Zacarias wrote:
> On 04/15/2015 07:20 PM, Bernhard Reutner-Fischer wrote:
>
>>> AS libc/sysdeps/linux/arm/syscall-eabi.os
>>
>> please show me that compiler invocation with V=2 ?
> -I./ldso/include -I. -Os -fstrict-aliasing -mthumb -mthumb-interwork
> In buildroot we do prebuild gcc --with-cpu, hence no need to specify
> that later (target=arm920t).
> With my patch it builds fine until the end.
So does just 4.8.4 on ARM with thumb1 need attribute_optimize("O2")
there or does -marm need it too?
What about 4.9.2 and 5 ?
thanks,
___
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On 16 April 2015 at 00:13, Gustavo Zacarias wrote:
> On 04/15/2015 05:01 PM, Bernhard Reutner-Fischer wrote:
>
>> These spill failures should be fixed on master, fyi.
>
> There's still one:
>
> -
> AS libc/sysdeps/linux/arm/syscall-eabi.os
please show me that compiler invocation with V=2 ?
> In file included from ldso/ldso/ldso.c:1438:0:
> ldso/ldso/dl-elf.c: In function '_dl_load_elf_shared_library':
> ldso/ldso/dl-elf.c:963:1: error: unable to find a register to spill in
> class 'LO_REGS'
> }
> ^
> ldso/ldso/dl-elf.c:963:1: error: this is the insn:
> (insn 679 677 680 87 (set (reg/v:SI 5 r5 [ _v2 ])
> (lshiftrt:SI (reg:SI 634)
> (const_int 13 [0xd]))) ./ldso/include/dl-syscall.h:220 128
> {*thumb1_lshrsi3}
> (expr_list:REG_DEAD (reg:SI 634)
> (nil)))
> ldso/ldso/dl-elf.c:963: confused by earlier errors, bailing out
> Makerules:393: recipe for target 'ldso/ldso/ldso.oS' failed
> make[1]: *** [ldso/ldso/ldso.oS] Error 1
> make[1]: *** Waiting for unfinished jobs
> CC libc/sysdeps/linux/common/umount.os
> make[1]: Leaving directory
> '/home/gustavoz/b/router01/output/build/uclibc-snapshot'
> package/pkg-generic.mk:183: recipe for target
> '/home/gustavoz/b/router01/output/build/uclibc-snapshot/.stamp_built' failed
> make: ***
> [/home/gustavoz/b/router01/output/build/uclibc-snapshot/.stamp_built]
> Error 2
> -
>
> I've patched that away via attribute_optimize("O2") but then i hit
> another snag:
>
> -
> CC libc/sysdeps/linux/common/getpgrp.os
> In file included from ./include/sys/syscall.h:33:0,
> from libc/sysdeps/linux/common/sync_file_range.c:10:
> libc/sysdeps/linux/common/sync_file_range.c: In function
> '__sync_file_range_nocancel':
> ./include/bits/syscalls.h:144:16: error: conflicting types for '_v3'
>register int _v3 __asm__ ("v3") = _v3tmp;
yea, i've pushed a fix for that one yesterday night.
thanks,
___
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On 04/15/2015 05:01 PM, Bernhard Reutner-Fischer wrote:
> These spill failures should be fixed on master, fyi.
There's still one:
-
AS libc/sysdeps/linux/arm/syscall-eabi.os
In file included from ldso/ldso/ldso.c:1438:0:
ldso/ldso/dl-elf.c: In function '_dl_load_elf_shared_library':
ldso/ldso/dl-elf.c:963:1: error: unable to find a register to spill in
class 'LO_REGS'
}
^
ldso/ldso/dl-elf.c:963:1: error: this is the insn:
(insn 679 677 680 87 (set (reg/v:SI 5 r5 [ _v2 ])
(lshiftrt:SI (reg:SI 634)
(const_int 13 [0xd]))) ./ldso/include/dl-syscall.h:220 128
{*thumb1_lshrsi3}
(expr_list:REG_DEAD (reg:SI 634)
(nil)))
ldso/ldso/dl-elf.c:963: confused by earlier errors, bailing out
Makerules:393: recipe for target 'ldso/ldso/ldso.oS' failed
make[1]: *** [ldso/ldso/ldso.oS] Error 1
make[1]: *** Waiting for unfinished jobs
CC libc/sysdeps/linux/common/umount.os
make[1]: Leaving directory
'/home/gustavoz/b/router01/output/build/uclibc-snapshot'
package/pkg-generic.mk:183: recipe for target
'/home/gustavoz/b/router01/output/build/uclibc-snapshot/.stamp_built' failed
make: ***
[/home/gustavoz/b/router01/output/build/uclibc-snapshot/.stamp_built]
Error 2
-
I've patched that away via attribute_optimize("O2") but then i hit
another snag:
-
CC libc/sysdeps/linux/common/getpgrp.os
In file included from ./include/sys/syscall.h:33:0,
from libc/sysdeps/linux/common/sync_file_range.c:10:
libc/sysdeps/linux/common/sync_file_range.c: In function
'__sync_file_range_nocancel':
./include/bits/syscalls.h:144:16: error: conflicting types for '_v3'
register int _v3 __asm__ ("v3") = _v3tmp;
^
./libc/sysdeps/linux/arm/sysdep.h:281:7: note: in expansion of macro
'LOAD_ARGS_7'
LOAD_ARGS_##nr (args) \
^
./libc/sysdeps/linux/arm/sysdep.h:324:2: note: in expansion of macro
'INTERNAL_SYSCALL_RAW'
INTERNAL_SYSCALL_RAW(SYS_ify(name), err, nr, args)
^
./libc/sysdeps/linux/arm/sysdep.h:256:40: note: in expansion of macro
'INTERNAL_SYSCALL'
({ unsigned int _inline_sys_result = INTERNAL_SYSCALL (name, , nr,
args); \
^
libc/sysdeps/linux/common/sync_file_range.c:32:9: note: in expansion of
macro 'INLINE_SYSCALL'
return INLINE_SYSCALL(sync_file_range, 7, fd, 0,
^
In file included from
./libpthread/nptl/sysdeps/unix/sysv/linux/arm/sysdep-cancel.h:18:0,
from ./include/cancel.h:58,
from libc/sysdeps/linux/common/sync_file_range.c:15:
./libc/sysdeps/linux/arm/sysdep.h:280:21: note: previous definition of
'_v3' was here
register int *_v3 __asm__ ("v3") = _sys_buf; \
^
./libc/sysdeps/linux/arm/sysdep.h:324:2: note: in expansion of macro
'INTERNAL_SYSCALL_RAW'
INTERNAL_SYSCALL_RAW(SYS_ify(name), err, nr, args)
^
./libc/sysdeps/linux/arm/sysdep.h:256:40: note: in expansion of macro
'INTERNAL_SYSCALL'
({ unsigned int _inline_sys_result = INTERNAL_SYSCALL (name, , nr,
args); \
^
libc/sysdeps/linux/common/sync_file_range.c:32:9: note: in expansion of
macro 'INLINE_SYSCALL'
return INLINE_SYSCALL(sync_file_range, 7, fd, 0,
^
./libc/sysdeps/linux/arm/sysdep.h:282:7: error: invalid type argument of
unary '*' (have 'int')
*_v3 = (int) (name); \
^
./libc/sysdeps/linux/arm/sysdep.h:324:2: note: in expansion of macro
'INTERNAL_SYSCALL_RAW'
INTERNAL_SYSCALL_RAW(SYS_ify(name), err, nr, args)
^
./libc/sysdeps/linux/arm/sysdep.h:256:40: note: in expansion of macro
'INTERNAL_SYSCALL'
({ unsigned int _inline_sys_result = INTERNAL_SYSCALL (name, , nr,
args); \
^
libc/sysdeps/linux/common/sync_file_range.c:32:9: note: in expansion of
macro 'INLINE_SYSCALL'
return INLINE_SYSCALL(sync_file_range, 7, fd, 0,
^
Makerules:392: recipe for target
'libc/sysdeps/linux/common/sync_file_range.os' failed
make[1]: *** [libc/sysdeps/linux/common/sync_file_range.os] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory
'/home/gustavoz/b/router01/output/build/uclibc-snapshot'
package/pkg-generic.mk:183: recipe for target
'/home/gustavoz/b/router01/output/build/uclibc-snapshot/.stamp_built' failed
make: ***
[/home/gustavoz/b/router01/output/build/uclibc-snapshot/.stamp_built]
Error 2
-
By the way, gcc 4.8.x is building good code as well with binutils 2.25,
so it seems gcc 4.9.x has some regression in thumb1.
Regards.
___
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On 15 April 2015 at 22:34, Sergiy Kibrik wrote: > On 4/15/15 1:37 PM, Bernhard Reutner-Fischer wrote: >> On 9 April 2015 at 20:02, Sergiy Kibrik wrote: >>> >>> On 4/8/15 10:04 AM, Bernhard Reutner-Fischer wrote: On April 6, 2015 10:08:57 PM GMT+02:00, Bernhard Reutner-Fischer wrote: > On April 5, 2015 9:30:30 PM GMT+02:00, Sergiy Kibrik > wrote: >> hi All, >> Recently I've been trying to use uClibc for quite old arm920t-based >> board. Do you use -mthumb-interwork ? >>> >>> yes, it's enabled by default in yocto >> >> I cannot reproduce this. >> The arm920t eabi image seems to boot fine with qemu for a -cpu arm926. > > isn't arm926 based on ARMv5T? Could be. Yes, it seems it is. There's no V4 support in qemu it seems, at least ATM. > >> Please send me your >> grep "memcpy\.o[sS]* " log.do_compile >> The file should be somewhere around your >> tmp-uclibc/work/armv4t-oe-linux-uclibceabi/uclibc/0.9.33+gitAUTOINC+*/temp/log.do_compile > > here it goes: http://pastebin.com/VGqf31ac arm-poky-linux-uclibceabi-gcc -march=armv4t -marm -mthumb-interwork -msoft-float -mlittle-endian -mthumb I see no notion of a tune? IIRC armv4t defaulted to arm7TDMI. Given that OE usually does not configure for a default CPU (AFAICS) you have to pass a proper tune. My 920t build used: arm-oe-linux-uclibceabi-gcc -march=armv4t -mthumb -mthumb-interwork -O2 -mtune=arm920t in your local.conf, try: FULL_OPTIMIZATION = "-O2 -mtune=arm920t" ARM_INSTRUCTION_SET := "thumb" maybe you need some additional settings like DEFAULTTUNE TUNE_ARCH TUNE_PKGARCH that you certainly use already. HTH, ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On 4/15/15 10:47 PM, Gustavo Zacarias wrote: > On 04/15/2015 07:37 AM, Bernhard Reutner-Fischer wrote: > >> I cannot reproduce this. >> The arm920t eabi image seems to boot fine with qemu for a -cpu arm926. >> >> Please send me your >> grep "memcpy\.o[sS]* " log.do_compile >> The file should be somewhere around your >> tmp-uclibc/work/armv4t-oe-linux-uclibceabi/uclibc/0.9.33+gitAUTOINC+*/temp/log.do_compile > > I've managed to reproduce this in buildroot with the latest uclibc snapshot. > > It seems to be toolchain-related, the table goes: > gcc 4.9.2 + binutils 2.25 + uclibc 0.9.33.2 = good > gcc 4.9.2 + binutils 2.25 + uclibc snapshot = bad > gcc 4.7.4 + binutils 2.22 + both uclibc versions = good > > I'll try to get more details, but i suspect gcc is at fault here. > Sergiy: which gcc version are you using? gcc 4.9.1 + binutils 2.24 > (BTW, in BR we build uclibc in ARM mode, EABI mandates interworking and > trying to build it in THUMB mode fails because of register exhaustion, > haven't tried with snapshot). > Regards. > > -- regards, Sergey signature.asc Description: OpenPGP digital signature ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On 4/15/15 1:37 PM, Bernhard Reutner-Fischer wrote: > On 9 April 2015 at 20:02, Sergiy Kibrik wrote: >> >> On 4/8/15 10:04 AM, Bernhard Reutner-Fischer wrote: >>> On April 6, 2015 10:08:57 PM GMT+02:00, Bernhard Reutner-Fischer >>> wrote: On April 5, 2015 9:30:30 PM GMT+02:00, Sergiy Kibrik wrote: > hi All, > Recently I've been trying to use uClibc for quite old arm920t-based > board. >>> >>> Do you use -mthumb-interwork ? >> >> yes, it's enabled by default in yocto > > I cannot reproduce this. > The arm920t eabi image seems to boot fine with qemu for a -cpu arm926. isn't arm926 based on ARMv5T? > Please send me your > grep "memcpy\.o[sS]* " log.do_compile > The file should be somewhere around your > tmp-uclibc/work/armv4t-oe-linux-uclibceabi/uclibc/0.9.33+gitAUTOINC+*/temp/log.do_compile here it goes: http://pastebin.com/VGqf31ac -- regards, Sergey signature.asc Description: OpenPGP digital signature ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On April 15, 2015 9:47:31 PM GMT+02:00, Gustavo Zacarias wrote: >On 04/15/2015 07:37 AM, Bernhard Reutner-Fischer wrote: > >> I cannot reproduce this. >> The arm920t eabi image seems to boot fine with qemu for a -cpu >arm926. >> >> Please send me your >> grep "memcpy\.o[sS]* " log.do_compile >> The file should be somewhere around your >> >tmp-uclibc/work/armv4t-oe-linux-uclibceabi/uclibc/0.9.33+gitAUTOINC+*/temp/log.do_compile > >I've managed to reproduce this in buildroot with the latest uclibc >snapshot. > >It seems to be toolchain-related, the table goes: >gcc 4.9.2 + binutils 2.25 + uclibc 0.9.33.2 = good >gcc 4.9.2 + binutils 2.25 + uclibc snapshot = bad >gcc 4.7.4 + binutils 2.22 + both uclibc versions = good > >I'll try to get more details, but i suspect gcc is at fault here. >Sergiy: which gcc version are you using? >(BTW, in BR we build uclibc in ARM mode, EABI mandates interworking and >trying to build it in THUMB mode fails because of register exhaustion, >haven't tried with snapshot). These spill failures should be fixed on master, fyi. ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On 04/15/2015 07:37 AM, Bernhard Reutner-Fischer wrote: > I cannot reproduce this. > The arm920t eabi image seems to boot fine with qemu for a -cpu arm926. > > Please send me your > grep "memcpy\.o[sS]* " log.do_compile > The file should be somewhere around your > tmp-uclibc/work/armv4t-oe-linux-uclibceabi/uclibc/0.9.33+gitAUTOINC+*/temp/log.do_compile I've managed to reproduce this in buildroot with the latest uclibc snapshot. It seems to be toolchain-related, the table goes: gcc 4.9.2 + binutils 2.25 + uclibc 0.9.33.2 = good gcc 4.9.2 + binutils 2.25 + uclibc snapshot = bad gcc 4.7.4 + binutils 2.22 + both uclibc versions = good I'll try to get more details, but i suspect gcc is at fault here. Sergiy: which gcc version are you using? (BTW, in BR we build uclibc in ARM mode, EABI mandates interworking and trying to build it in THUMB mode fails because of register exhaustion, haven't tried with snapshot). Regards. ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On 9 April 2015 at 20:02, Sergiy Kibrik wrote: > > On 4/8/15 10:04 AM, Bernhard Reutner-Fischer wrote: >> On April 6, 2015 10:08:57 PM GMT+02:00, Bernhard Reutner-Fischer >> wrote: >>> On April 5, 2015 9:30:30 PM GMT+02:00, Sergiy Kibrik >>> wrote: hi All, Recently I've been trying to use uClibc for quite old arm920t-based board. >> >> Do you use -mthumb-interwork ? > > yes, it's enabled by default in yocto I cannot reproduce this. The arm920t eabi image seems to boot fine with qemu for a -cpu arm926. Please send me your grep "memcpy\.o[sS]* " log.do_compile The file should be somewhere around your tmp-uclibc/work/armv4t-oe-linux-uclibceabi/uclibc/0.9.33+gitAUTOINC+*/temp/log.do_compile TIA, ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On 4/8/15 10:04 AM, Bernhard Reutner-Fischer wrote: > On April 6, 2015 10:08:57 PM GMT+02:00, Bernhard Reutner-Fischer > wrote: >> On April 5, 2015 9:30:30 PM GMT+02:00, Sergiy Kibrik >> wrote: >>> hi All, >>> Recently I've been trying to use uClibc for quite old arm920t-based >>> board. > > Do you use -mthumb-interwork ? yes, it's enabled by default in yocto -- regards, Sergey signature.asc Description: OpenPGP digital signature ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On April 6, 2015 10:08:57 PM GMT+02:00, Bernhard Reutner-Fischer wrote: >On April 5, 2015 9:30:30 PM GMT+02:00, Sergiy Kibrik >wrote: >>hi All, >>Recently I've been trying to use uClibc for quite old arm920t-based >>board. Do you use -mthumb-interwork ? Thanks, ___ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On April 5, 2015 9:30:30 PM GMT+02:00, Sergiy Kibrik wrote:
>hi All,
>Recently I've been trying to use uClibc for quite old arm920t-based
>board. Some busybox applications (like shell, mount, hostname, wget)
>would get killed with SIGILL. I managed to debug it down to leaving
>memcpy() routine, namely to the following code from
>libc/string/arm/memcpy.S:
>
>[..]
>.thumb_func
>memcpy:
> push{r0, lr}
> bl _memcpy
> POP_RET
>[..]
>
>POP_RET defined as pop {r2, pc} in [1]. On armv4t is just won't switch
>CPU back to arm mode, so in my case it seems to be jumping to calling
>arm routine while still being in thumb mode.
>
>I'm not sure if this is the case, but I've also found couple of
>comments
>in code:
>http://git.uclibc.org/uClibc/tree/ldso/ldso/arm/resolve.S#n62
>http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/arm/crtn.S#n10
>
>stating that some parts aren't even supposed to work on armv4t.
>Has armv4t been deprecated for good (I use master branch currently)?
I think this was a mere accident. Patches are welcome!
TIA,
>Thanks.
>
>[1]
>http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/arm/bits/arm_asm.h#n15
___
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
On 4/6/15 6:32 PM, Waldemar Brodkorb wrote:
> Hi,
> Sergiy Kibrik wrote,
>
>> hi All,
>> Recently I've been trying to use uClibc for quite old arm920t-based
>> board. Some busybox applications (like shell, mount, hostname, wget)
>> would get killed with SIGILL. I managed to debug it down to leaving
>> memcpy() routine, namely to the following code from
>> libc/string/arm/memcpy.S:
>>
>> [..]
>> .thumb_func
>> memcpy:
>> push{r0, lr}
>> bl _memcpy
>> POP_RET
>> [..]
>>
>> POP_RET defined as pop {r2, pc} in [1]. On armv4t is just won't switch
>> CPU back to arm mode, so in my case it seems to be jumping to calling
>> arm routine while still being in thumb mode.
>>
>> I'm not sure if this is the case, but I've also found couple of comments
>> in code:
>> http://git.uclibc.org/uClibc/tree/ldso/ldso/arm/resolve.S#n62
>> http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/arm/crtn.S#n10
>>
>> stating that some parts aren't even supposed to work on armv4t.
>> Has armv4t been deprecated for good (I use master branch currently)?
>> Thanks.
>
> Does it work with uClibc 0.9.33 release?
didn't actually tried 0.9.33, as I used yocto 1.7 to build rootfs, it
fetches uclibc from master only
> What board is this?
it's Netronix eb600 (e-book reader), based on samsung s3c2440 SoC
> Are you tried running thumb-only?
>
no, but I tried running ARM-only, and it seems to be working (though I
didn't run any tests)
--
regards,
Sergey
signature.asc
Description: OpenPGP digital signature
___
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
Re: is ARMv4T deprecated?
Hi,
Sergiy Kibrik wrote,
> hi All,
> Recently I've been trying to use uClibc for quite old arm920t-based
> board. Some busybox applications (like shell, mount, hostname, wget)
> would get killed with SIGILL. I managed to debug it down to leaving
> memcpy() routine, namely to the following code from
> libc/string/arm/memcpy.S:
>
> [..]
> .thumb_func
> memcpy:
> push{r0, lr}
> bl _memcpy
> POP_RET
> [..]
>
> POP_RET defined as pop {r2, pc} in [1]. On armv4t is just won't switch
> CPU back to arm mode, so in my case it seems to be jumping to calling
> arm routine while still being in thumb mode.
>
> I'm not sure if this is the case, but I've also found couple of comments
> in code:
> http://git.uclibc.org/uClibc/tree/ldso/ldso/arm/resolve.S#n62
> http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/arm/crtn.S#n10
>
> stating that some parts aren't even supposed to work on armv4t.
> Has armv4t been deprecated for good (I use master branch currently)?
> Thanks.
Does it work with uClibc 0.9.33 release?
What board is this?
Are you tried running thumb-only?
best regards
Waldemar
___
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
