Re: [U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds
On 2014-11-20 20:14, Jeroen Hofstee wrote:
Hi,
On 20-11-14 19:21, Bill Pringlemeir wrote:
---
arch/arm/lib/memset.S | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm/lib/memset.S b/arch/arm/lib/memset.S
index 0cdf895..4fe38f6 100644
--- a/arch/arm/lib/memset.S
+++ b/arch/arm/lib/memset.S
-18,8 +18,8 @@
1:subsr2, r2, #4 @ 1 do we have enough
blt 5f @ 1 bytes to align with?
cmp r3, #2 @ 1
- strltb r1, [r0], #1@ 1
- strleb r1, [r0], #1@ 1
+ strblt r1, [r0], #1@ 1
+ strble r1, [r0], #1@ 1
To test this, can we just use 'objdump'. The hex codes should be
identical; there is only one encoding. It should produce the same
binaries. No need to run test-suites, etc.
On 20 Nov 2014, jer...@myspectrum.nl wrote:
yes, I should be trivial to test (and find the trivial problem, with
the patch I attached). I am wondering though if all version of
gas accept the suffix notation... any idea?
One part of the answer is here,
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=history;f=gas/config/tc-arm.c;hb=HEAD
The 'strCCb' version is definitely more popular in older ARM books.
Certainly there could be bugs and/or patched versions that make a
difference. Probably it would be helpful to know what versions are
supported.
Back in 1999 it seems that the code at least tries to take conditions
anywhere,
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-arm.c;hb=858f4ff6ff40a73f2a569fc8886157568f08c6db#l6099
I think it is most likely to result in a parse error if it wasn't
supported. Any version since Thumb2/Unified (2003-2005?) was introduced
should be accepting this syntax with less issues. Ie, it seems like a
better way forward.
Historical versions are here,
http://ftp.mirrorservice.org/sites/sourceware.org/pub/binutils/old-releases/
Who knows if some vendor patched things to mess something up? Probably
grabbing an older 'gas' version and verifying it was the same binary
before/after the patch would probably be fair confirmation? I don't
think you can 100% guarantee this doesn't break with some archaic
vendors gas.
Ok thanks for digging that up, that doesn't sound like a problem
then. Stefan, can you check if you can actually fix the warnings
instead of suppressing them?
Ok, I could apply the changes from your patch and it fixed the warnings
in memset.S. However, when I build the file in ARM mode then (without
CONFIG_SYS_THUMB_BUILD set). I get this:
arch/arm/lib/memset.S: Assembler messages:
arch/arm/lib/memset.S:92: Error: bad instruction `stmiage
ip!,{r1,r3-r8,lr}'
arch/arm/lib/memset.S:93: Error: bad instruction `stmiage
ip!,{r1,r3-r8,lr}'
arch/arm/lib/memset.S:95: Error: bad instruction `ldmfdeq
sp!,{r4-r8,pc}'
arch/arm/lib/memset.S:98: Error: bad instruction `stmiane
ip!,{r1,r3-r8,lr}'
arch/arm/lib/memset.S:100: Error: bad instruction `stmiane ip!,{r4-r7}'
arch/arm/lib/memset.S:106: Error: bad instruction `stmiane ip!,{r1,r3}'
arch/arm/lib/memset.S:114: Error: bad instruction `strbne r1,[ip],#1'
arch/arm/lib/memset.S:115: Error: bad instruction `strbne r1,[ip],#1'
arch/arm/lib/memset.S:117: Error: bad instruction `strbne r1,[ip],#1'
arch/arm/lib/memset.S:123: Error: bad instruction `strblt r1,[ip],#1'
arch/arm/lib/memset.S:124: Error: bad instruction `strble r1,[ip],#1'
--
Stefan
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds
Hello Jeroen, Adding Stefan as it seems he was dropped from the recipients list. Plus : On Thu, 20 Nov 2014 20:14:01 +0100, Jeroen Hofstee jer...@myspectrum.nl wrote: Hi, On 20-11-14 19:21, Bill Pringlemeir wrote: --- arch/arm/lib/memset.S | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/arch/arm/lib/memset.S b/arch/arm/lib/memset.S index 0cdf895..4fe38f6 100644 --- a/arch/arm/lib/memset.S +++ b/arch/arm/lib/memset.S -18,8 +18,8 @@ 1: subsr2, r2, #4 @ 1 do we have enough blt 5f @ 1 bytes to align with? cmp r3, #2 @ 1 -strltb r1, [r0], #1@ 1 -strleb r1, [r0], #1@ 1 +strblt r1, [r0], #1@ 1 +strble r1, [r0], #1@ 1 To test this, can we just use 'objdump'. The hex codes should be identical; there is only one encoding. It should produce the same binaries. No need to run test-suites, etc. On 20 Nov 2014, jer...@myspectrum.nl wrote: yes, I should be trivial to test (and find the trivial problem, with the patch I attached). I am wondering though if all version of gas accept the suffix notation... any idea? One part of the answer is here, https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=history;f=gas/config/tc-arm.c;hb=HEAD The 'strCCb' version is definitely more popular in older ARM books. Certainly there could be bugs and/or patched versions that make a difference. Probably it would be helpful to know what versions are supported. Back in 1999 it seems that the code at least tries to take conditions anywhere, https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-arm.c;hb=858f4ff6ff40a73f2a569fc8886157568f08c6db#l6099 I think it is most likely to result in a parse error if it wasn't supported. Any version since Thumb2/Unified (2003-2005?) was introduced should be accepting this syntax with less issues. Ie, it seems like a better way forward. Historical versions are here, http://ftp.mirrorservice.org/sites/sourceware.org/pub/binutils/old-releases/ Who knows if some vendor patched things to mess something up? Probably grabbing an older 'gas' version and verifying it was the same binary before/after the patch would probably be fair confirmation? I don't think you can 100% guarantee this doesn't break with some archaic vendors gas. Ok thanks for digging that up, that doesn't sound like a problem then. Stefan, can you check if you can actually fix the warnings instead of suppressing them? (in the right thread this time) Stefan, can you also drop the -mauto-it part? Regards, Jeroen Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds
On 2014-11-20 20:14, Jeroen Hofstee wrote:
Ok thanks for digging that up, that doesn't sound like a problem
then. Stefan, can you check if you can actually fix the warnings
instead of suppressing them?
On 21 Nov 2014, ste...@agner.ch wrote:
Ok, I could apply the changes from your patch and it fixed the
warnings in memset.S. However, when I build the file in ARM mode then
(without CONFIG_SYS_THUMB_BUILD set). I get this:
arch/arm/lib/memset.S: Assembler messages: arch/arm/lib/memset.S:92:
Error: bad instruction `stmiage ip!,{r1,r3-r8,lr}'
I think you need '.syntax unified' if you want those in ARM mode. I
guess you found that out too? I see,
+ .syntax unified
+#ifdef CONFIG_SYS_THUMB_BUILD
+ .thumb
+ .thumb_func
+#endif
in '[PATCH v2] arm: build arch memset/memcpy in Thumb2 mode'; so this
solved it?
I think it is a very nice feature to have Thumb2 on Vybrid. Many boot
devices may have limited bandwidth compared to the running system.
Thanks for your work.
Regards,
Bill Pringlemeir
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds
Hello Stefan, On 19-11-14 15:16, Stefan Agner wrote: Resynchronize memcpy/memset with kernel and build them explicitly in Thumb2 mode (unified syntax). Those assembler files can be built and linked in ARM mode too, however when calling them from Thumb2 built code, the stack got corrupted and the copy did not succeed (the exact details have not been traced back). Hoever, the Linux kernel builds those files in Thumb2 mode. Hence U-Boot should build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD is set. Also add implicit-it=always to AFLAGS when building for Thumb2. Furthermore add no-warn-deprecated option to AFLAGS to rid of deprecated unified syntax: arch/arm/lib/memcpy.S: Assembler messages: arch/arm/lib/memcpy.S:153: Warning: conditional infixes are deprecated in unified syntax arch/arm/lib/memcpy.S:154: Warning: conditional infixes are deprecated in unified syntax ... Any particular reason not to fix these warnings instead? It Is just a matter of making the conditionals suffixes. [I guess you can even disassemble to file to get the UAL represenation]. Or are there gas version around which actually choke on that? Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds
Hi Jeroen, On 2014-11-20 10:21, Jeroen Hofstee wrote: Hello Stefan, On 19-11-14 15:16, Stefan Agner wrote: Resynchronize memcpy/memset with kernel and build them explicitly in Thumb2 mode (unified syntax). Those assembler files can be built and linked in ARM mode too, however when calling them from Thumb2 built code, the stack got corrupted and the copy did not succeed (the exact details have not been traced back). Hoever, the Linux kernel builds those files in Thumb2 mode. Hence U-Boot should build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD is set. Also add implicit-it=always to AFLAGS when building for Thumb2. Furthermore add no-warn-deprecated option to AFLAGS to rid of deprecated unified syntax: arch/arm/lib/memcpy.S: Assembler messages: arch/arm/lib/memcpy.S:153: Warning: conditional infixes are deprecated in unified syntax arch/arm/lib/memcpy.S:154: Warning: conditional infixes are deprecated in unified syntax ... Any particular reason not to fix these warnings instead? It Is just a matter of making the conditionals suffixes. [I guess you can even disassemble to file to get the UAL represenation]. Or are there gas version around which actually choke on that? No particular reason, I did not know how to fix this without digging into it. Hence, after I discovered this, I checked why those warnings do not happen for the kernel, then I applied just the AFLAGS the kernel is using. I guess fixing the underlying issue is the better option, and doing this also for the kernel would be the best way... Maybe the kernel community also knows better why they choose to use the AFLAGS instead (and if there are gas version which do have problems with a proper fix)... -- Stefan Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds
Hello Stefan,
On 20-11-14 13:15, Stefan Agner wrote:
Hi Jeroen,
On 2014-11-20 10:21, Jeroen Hofstee wrote:
Hello Stefan,
On 19-11-14 15:16, Stefan Agner wrote:
Resynchronize memcpy/memset with kernel and build them explicitly
in Thumb2 mode (unified syntax). Those assembler files can be
built and linked in ARM mode too, however when calling them from
Thumb2 built code, the stack got corrupted and the copy did not
succeed (the exact details have not been traced back). Hoever,
the Linux kernel builds those files in Thumb2 mode. Hence U-Boot
should build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD
is set.
Also add implicit-it=always to AFLAGS when building for Thumb2.
Furthermore add no-warn-deprecated option to AFLAGS to rid of
deprecated unified syntax:
arch/arm/lib/memcpy.S: Assembler messages:
arch/arm/lib/memcpy.S:153: Warning: conditional infixes are deprecated in
unified syntax
arch/arm/lib/memcpy.S:154: Warning: conditional infixes are deprecated in
unified syntax
...
Any particular reason not to fix these warnings instead? It Is
just a matter of making the conditionals suffixes. [I guess
you can even disassemble to file to get the UAL represenation].
Or are there gas version around which actually choke on that?
No particular reason, I did not know how to fix this without digging
into it. Hence, after I discovered this, I checked why those warnings do
not happen for the kernel, then I applied just the AFLAGS the kernel is
using. I guess fixing the underlying issue is the better option, and
doing this also for the kernel would be the best way... Maybe the kernel
community also knows better why they choose to use the AFLAGS instead
(and if there are gas version which do have problems with a proper
fix)...
for what it is worth, I have attached patch hanging around, but I never
actually tested it. It is for the current version.
Regards,
Jeroen
From c151254b3de49d8fccb69ab4f9442d884b9ff85c Mon Sep 17 00:00:00 2001
From: Jeroen Hofstee jer...@myspectrum.nl
Date: Thu, 20 Nov 2014 14:06:26 +0100
Subject: [PATCH] arm: memset: make it UAL compliant
---
arch/arm/lib/memset.S | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm/lib/memset.S b/arch/arm/lib/memset.S
index 0cdf895..4fe38f6 100644
--- a/arch/arm/lib/memset.S
+++ b/arch/arm/lib/memset.S
@@ -18,8 +18,8 @@
1: subs r2, r2, #4 @ 1 do we have enough
blt 5f @ 1 bytes to align with?
cmp r3, #2 @ 1
- strltb r1, [r0], #1 @ 1
- strleb r1, [r0], #1 @ 1
+ strblt r1, [r0], #1 @ 1
+ strble r1, [r0], #1 @ 1
strb r1, [r0], #1 @ 1
add r2, r2, r3 @ 1 (r2 = r2 - (4 - r3))
/*
@@ -51,20 +51,20 @@ memset:
mov lr, r1
2: subs r2, r2, #64
- stmgeia r0!, {r1, r3, ip, lr} @ 64 bytes at a time.
- stmgeia r0!, {r1, r3, ip, lr}
- stmgeia r0!, {r1, r3, ip, lr}
- stmgeia r0!, {r1, r3, ip, lr}
+ stmiage r0!, {r1, r3, ip, lr} @ 64 bytes at a time.
+ stmiage r0!, {r1, r3, ip, lr}
+ stmiage r0!, {r1, r3, ip, lr}
+ stmiage r0!, {r1, r3, ip, lr}
bgt 2b
ldmeqfd sp!, {pc} @ Now 64 bytes to go.
/*
* No need to correct the count; we're only testing bits from now on
*/
tst r2, #32
- stmneia r0!, {r1, r3, ip, lr}
- stmneia r0!, {r1, r3, ip, lr}
+ stmiage r0!, {r1, r3, ip, lr}
+ stmiage r0!, {r1, r3, ip, lr}
tst r2, #16
- stmneia r0!, {r1, r3, ip, lr}
+ stmiage r0!, {r1, r3, ip, lr}
ldr lr, [sp], #4
#else
@@ -90,28 +90,28 @@ memset:
rsb ip, ip, #32
sub r2, r2, ip
movs ip, ip, lsl #(32 - 4)
- stmcsia r0!, {r4, r5, r6, r7}
- stmmiia r0!, {r4, r5}
+ stmiacs r0!, {r4, r5, r6, r7}
+ stmiami r0!, {r4, r5}
tst ip, #(1 30)
mov ip, r1
strne r1, [r0], #4
3: subs r2, r2, #64
- stmgeia r0!, {r1, r3-r7, ip, lr}
- stmgeia r0!, {r1, r3-r7, ip, lr}
+ stmiage r0!, {r1, r3-r7, ip, lr}
+ stmiage r0!, {r1, r3-r7, ip, lr}
bgt 3b
- ldmeqfd sp!, {r4-r7, pc}
+ ldmfdeq sp!, {r4-r7, pc}
tst r2, #32
- stmneia r0!, {r1, r3-r7, ip, lr}
+ stmiage r0!, {r1, r3-r7, ip, lr}
tst r2, #16
- stmneia r0!, {r4-r7}
+ stmiage r0!, {r4-r7}
ldmfd sp!, {r4-r7, lr}
#endif
4: tst r2, #8
- stmneia r0!, {r1, r3}
+ stmiage r0!, {r1, r3}
tst r2, #4
strne r1, [r0], #4
/*
@@ -119,8 +119,8 @@ memset:
* may have an unaligned pointer as well.
*/
5: tst r2, #2
- strneb r1, [r0], #1
- strneb r1, [r0], #1
+ strbne r1, [r0], #1
+ strbne r1, [r0], #1
tst r2, #1
- strneb r1, [r0], #1
+ strbne r1, [r0], #1
mov pc, lr
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds
On 20-11-14 13:15, Stefan Agner wrote: No particular reason, I did not know how to fix this without digging into it. Hence, after I discovered this, I checked why those warnings do not happen for the kernel, then I applied just the AFLAGS the kernel is using. I guess fixing the underlying issue is the better option, and doing this also for the kernel would be the best way... Maybe the kernel community also knows better why they choose to use the AFLAGS instead (and if there are gas version which do have problems with a proper fix)... On 20 Nov 2014, jer...@myspectrum.nl wrote: for what it is worth, I have attached patch hanging around, but I never actually tested it. It is for the current version. From c151254b3de49d8fccb69ab4f9442d884b9ff85c Mon Sep 17 00:00:00 2001 From: Jeroen Hofstee jer...@myspectrum.nl Date: Thu, 20 Nov 2014 14:06:26 +0100 Subject: [PATCH] arm: memset: make it UAL compliant --- arch/arm/lib/memset.S | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/arch/arm/lib/memset.S b/arch/arm/lib/memset.S index 0cdf895..4fe38f6 100644 --- a/arch/arm/lib/memset.S +++ b/arch/arm/lib/memset.S @@ -18,8 +18,8 @@ 1:subsr2, r2, #4 @ 1 do we have enough blt 5f @ 1 bytes to align with? cmp r3, #2 @ 1 - strltb r1, [r0], #1@ 1 - strleb r1, [r0], #1@ 1 + strblt r1, [r0], #1@ 1 + strble r1, [r0], #1@ 1 To test this, can we just use 'objdump'. The hex codes should be identical; there is only one encoding. It should produce the same binaries. No need to run test-suites, etc. Fwiw, Bill. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds
Hi, On 20-11-14 16:18, Bill Pringlemeir wrote: --- arch/arm/lib/memset.S | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/arch/arm/lib/memset.S b/arch/arm/lib/memset.S index 0cdf895..4fe38f6 100644 --- a/arch/arm/lib/memset.S +++ b/arch/arm/lib/memset.S @@ -18,8 +18,8 @@ 1: subsr2, r2, #4 @ 1 do we have enough blt 5f @ 1 bytes to align with? cmp r3, #2 @ 1 - strltb r1, [r0], #1@ 1 - strleb r1, [r0], #1@ 1 + strblt r1, [r0], #1@ 1 + strble r1, [r0], #1@ 1 To test this, can we just use 'objdump'. The hex codes should be identical; there is only one encoding. It should produce the same binaries. No need to run test-suites, etc. yes, I should be trivial to test (and find the trivial problem, with the patch I attached). I am wondering though if all version of gas accept the suffix notation... any idea? Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds
--- arch/arm/lib/memset.S | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/arch/arm/lib/memset.S b/arch/arm/lib/memset.S index 0cdf895..4fe38f6 100644 --- a/arch/arm/lib/memset.S +++ b/arch/arm/lib/memset.S -18,8 +18,8 @@ 1: subsr2, r2, #4 @ 1 do we have enough blt 5f @ 1 bytes to align with? cmp r3, #2 @ 1 - strltb r1, [r0], #1@ 1 - strleb r1, [r0], #1@ 1 + strblt r1, [r0], #1@ 1 + strble r1, [r0], #1@ 1 To test this, can we just use 'objdump'. The hex codes should be identical; there is only one encoding. It should produce the same binaries. No need to run test-suites, etc. On 20 Nov 2014, jer...@myspectrum.nl wrote: yes, I should be trivial to test (and find the trivial problem, with the patch I attached). I am wondering though if all version of gas accept the suffix notation... any idea? One part of the answer is here, https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=history;f=gas/config/tc-arm.c;hb=HEAD The 'strCCb' version is definitely more popular in older ARM books. Certainly there could be bugs and/or patched versions that make a difference. Probably it would be helpful to know what versions are supported. Back in 1999 it seems that the code at least tries to take conditions anywhere, https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-arm.c;hb=858f4ff6ff40a73f2a569fc8886157568f08c6db#l6099 I think it is most likely to result in a parse error if it wasn't supported. Any version since Thumb2/Unified (2003-2005?) was introduced should be accepting this syntax with less issues. Ie, it seems like a better way forward. Historical versions are here, http://ftp.mirrorservice.org/sites/sourceware.org/pub/binutils/old-releases/ Who knows if some vendor patched things to mess something up? Probably grabbing an older 'gas' version and verifying it was the same binary before/after the patch would probably be fair confirmation? I don't think you can 100% guarantee this doesn't break with some archaic vendors gas. Fwiw, Bill Pringlemeir. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds
Hi, On 20-11-14 19:21, Bill Pringlemeir wrote: --- arch/arm/lib/memset.S | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/arch/arm/lib/memset.S b/arch/arm/lib/memset.S index 0cdf895..4fe38f6 100644 --- a/arch/arm/lib/memset.S +++ b/arch/arm/lib/memset.S -18,8 +18,8 @@ 1: subsr2, r2, #4 @ 1 do we have enough blt 5f @ 1 bytes to align with? cmp r3, #2 @ 1 - strltb r1, [r0], #1@ 1 - strleb r1, [r0], #1@ 1 + strblt r1, [r0], #1@ 1 + strble r1, [r0], #1@ 1 To test this, can we just use 'objdump'. The hex codes should be identical; there is only one encoding. It should produce the same binaries. No need to run test-suites, etc. On 20 Nov 2014, jer...@myspectrum.nl wrote: yes, I should be trivial to test (and find the trivial problem, with the patch I attached). I am wondering though if all version of gas accept the suffix notation... any idea? One part of the answer is here, https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=history;f=gas/config/tc-arm.c;hb=HEAD The 'strCCb' version is definitely more popular in older ARM books. Certainly there could be bugs and/or patched versions that make a difference. Probably it would be helpful to know what versions are supported. Back in 1999 it seems that the code at least tries to take conditions anywhere, https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-arm.c;hb=858f4ff6ff40a73f2a569fc8886157568f08c6db#l6099 I think it is most likely to result in a parse error if it wasn't supported. Any version since Thumb2/Unified (2003-2005?) was introduced should be accepting this syntax with less issues. Ie, it seems like a better way forward. Historical versions are here, http://ftp.mirrorservice.org/sites/sourceware.org/pub/binutils/old-releases/ Who knows if some vendor patched things to mess something up? Probably grabbing an older 'gas' version and verifying it was the same binary before/after the patch would probably be fair confirmation? I don't think you can 100% guarantee this doesn't break with some archaic vendors gas. Ok thanks for digging that up, that doesn't sound like a problem then. Stefan, can you check if you can actually fix the warnings instead of suppressing them? Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds
Resynchronize memcpy/memset with kernel and build them explicitly in Thumb2 mode (unified syntax). Those assembler files can be built and linked in ARM mode too, however when calling them from Thumb2 built code, the stack got corrupted and the copy did not succeed (the exact details have not been traced back). Hoever, the Linux kernel builds those files in Thumb2 mode. Hence U-Boot should build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD is set. Also add implicit-it=always to AFLAGS when building for Thumb2. Furthermore add no-warn-deprecated option to AFLAGS to rid of deprecated unified syntax: arch/arm/lib/memcpy.S: Assembler messages: arch/arm/lib/memcpy.S:153: Warning: conditional infixes are deprecated in unified syntax arch/arm/lib/memcpy.S:154: Warning: conditional infixes are deprecated in unified syntax ... Signed-off-by: Stefan Agner ste...@agner.ch --- This patch grew out of a issue we have seen on our Vybrid based module. My first proposal only covered memcpy. This patchset synchronizes the memcpy/memset assembly with the kernel and makes sure both files are built in Thumb mode. This patchset is tested with Vybrid in ARM and Thumb2 mode. arch/arm/config.mk | 5 +- arch/arm/include/asm/assembler.h | 33 ++-- arch/arm/lib/memcpy.S| 75 ++ arch/arm/lib/memset.S| 112 --- 4 files changed, 141 insertions(+), 84 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index f0eafd6..7336455 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -26,7 +26,10 @@ PLATFORM_CPPFLAGS += -D__ARM__ # Choose between ARM/Thumb instruction sets ifeq ($(CONFIG_SYS_THUMB_BUILD),y) -PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\ +AFLAGS_AUTOIT := $(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it) +AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W) +PF_CPPFLAGS_ARM := $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN) \ + $(call cc-option, -mthumb -mthumb-interwork,\ $(call cc-option,-marm,)\ $(call cc-option,-mno-thumb-interwork,)\ ) diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 5e4789b..11b80fb 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -14,12 +14,14 @@ * assembler source. */ +#include config.h + /* * Endian independent macros for shifting bytes within registers. */ #ifndef __ARMEB__ -#define pull lsr -#define push lsl +#define lspull lsr +#define lspush lsl #define get_byte_0 lsl #0 #define get_byte_1 lsr #8 #define get_byte_2 lsr #16 @@ -29,8 +31,8 @@ #define put_byte_2 lsl #16 #define put_byte_3 lsl #24 #else -#define pull lsl -#define push lsr +#define lspull lsl +#define lspush lsr #define get_byte_0 lsr #24 #define get_byte_1 lsr #16 #define get_byte_2 lsr #8 @@ -54,7 +56,28 @@ #define PLD(code...) #endif + .irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo + .macro ret\c, reg +#if defined(__ARM_ARCH_5E__) || defined(__ARM_ARCH_5TE__) + mov\c pc, \reg +#else + .ifeqs \reg, lr + bx\c\reg + .else + mov\c pc, \reg + .endif +#endif + .endm + .endr + /* - * Cache alligned + * Cache aligned, used for optimized memcpy/memset + * In the kernel this is only enabled for Feroceon CPU's... + * We disable it especially for Thumb builds since those instructions + * are not made in a Thumb ready way... */ +#ifdef CONFIG_SYS_THUMB_BUILD +#define CALGN(code...) +#else #define CALGN(code...) code +#endif diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S index f655256..c9424ba 100644 --- a/arch/arm/lib/memcpy.S +++ b/arch/arm/lib/memcpy.S @@ -10,9 +10,14 @@ * published by the Free Software Foundation. */ +#include linux/linkage.h #include asm/assembler.h +#ifdef CONFIG_SYS_THUMB_BUILD +#define W(instr) instr.w +#else #define W(instr) instr +#endif #define LDR1W_SHIFT0 #define STR1W_SHIFT0 @@ -56,13 +61,16 @@ .text /* Prototype: void *memcpy(void *dest, const void *src, size_t n); */ - -.globl memcpy -memcpy: - +#ifdef CONFIG_SYS_THUMB_BUILD + .syntax unified + .thumb + .thumb_func +#endif +ENTRY(memcpy) +/* cmp r0, r1 moveq pc, lr - +*/ enter r4, lr subsr2, r2, #4 @@ -193,24 +201,24 @@ memcpy: 12:PLD(pld [r1, #124] ) 13:ldr4w r1, r4, r5, r6, r7, abort=19f - mov r3, lr, pull #\pull + mov r3, lr, lspull #\pull subsr2, r2, #32 ldr4w r1, r8, r9, ip, lr, abort=19f - orr r3, r3,
