[U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds

[Jeroen Hofstee <jeroen@myspectrum.nl>]

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:	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.
> On 20 Nov 2014, jeroen at 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