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, jeroen@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 jeroen@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
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.