From: Bill Pringlemeir <bpringlemeir@nbsps.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds
Date: Thu, 20 Nov 2014 13:21:15 -0500 [thread overview]
Message-ID: <87vbm9lomc.fsf@nbsps.com> (raw)
In-Reply-To: <546E0E7D.90203@myspectrum.nl> (Jeroen Hofstee's message of "Thu, 20 Nov 2014 16:53:33 +0100")
>>> ---
>>> 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.
Fwiw,
Bill Pringlemeir.
next prev parent reply other threads:[~2014-11-20 18:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 14:16 [U-Boot] [PATCH] arm: make arch memset/memcpy to work with Thumb2 builds Stefan Agner
2014-11-20 9:21 ` Jeroen Hofstee
2014-11-20 12:15 ` Stefan Agner
2014-11-20 13:10 ` Jeroen Hofstee
2014-11-20 15:18 ` Bill Pringlemeir
2014-11-20 15:53 ` Jeroen Hofstee
2014-11-20 18:21 ` Bill Pringlemeir [this message]
2014-11-20 19:14 ` Jeroen Hofstee
2014-11-21 15:10 ` Stefan Agner
2014-11-21 16:45 ` Bill Pringlemeir
2014-11-21 15:43 ` Albert ARIBAUD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vbm9lomc.fsf@nbsps.com \
--to=bpringlemeir@nbsps.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox