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@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/con...
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...
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