public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jiong Wang <jiong.wang@foss.arm.com>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>
Cc: Binutils <binutils@sourceware.org>, Rich Felker <dalias@libc.org>,
	Reiner Herrmann <reiner@reiner-h.de>
Subject: Re: [ARM] Allow MOV/MOV.W to accept all possible immediates
Date: Thu, 05 Jan 2017 14:16:00 -0000	[thread overview]
Message-ID: <039ff06e-19a5-214f-0b68-feececcea951@foss.arm.com> (raw)
In-Reply-To: <ac3ec52b-2e8a-a4f4-d144-c5d61c3de31e@foss.arm.com>

On 05/01/17 13:59, Jiong Wang wrote:
> On 05/01/17 10:49, Szabolcs Nagy wrote:
>> adding the reporter to cc and rich because it broke musl.
>>
>> On 05/01/17 10:45, Szabolcs Nagy wrote:
>>> On 01/11/16 12:21, Jiong Wang wrote:
>>>> Hi,
>>>>
>>>>    AArch32 MOV Rd, #imm should accept all immediates which can be 
>>>> encoded into
>>>> available encoding, A1/A2 for ARM, T1/T2/T3 for Thumb/Thumb2, and 
>>>> MOV is the
>>>> preferred disassembly syntax.  See latest ARM Architecture 
>>>> Reference Manual for
>>>> ARMv8-A, section F6.1.108 and for ARMv8-M, section C2.4.89.
>>>>
>>>>    The same for MOV.W under Thumb mode.  It should try all possible 
>>>> 32-bit Thumb
>>>> encoding instead of T2 only.
>>>>
>>>>    This patch let MOV/MOV.W accept more immediate formats while 
>>>> their currently
>>>> supported immediate formats are not affected, so there is no 
>>>> backward compatibility
>>>> issue, also this patch haven't touched the disassembler.
>>>>
>>>>    I think this patch brings GAS closer to ARM Architecture 
>>>> Reference Manual.
>>>>
>>>>    OK for master?
>>>>
>>>> gas/
>>>> 2016-11-01  Jiong Wang  <jiong.wang@arm.com>
>>>>                            * config/tc-arm.c (SBIT_SHIFT): New.
>>>>          (T2_SBIT_SHIFT): Likewise.
>>>>          (t32_insn_ok): Return TRUE for MOV in ARMv8-M Baseline.
>>>>          (md_apply_fix): Try UINT16 encoding when ARM/Thumb 
>>>> modified immediate
>>>>          encoding failed.
>>>>          * testsuite/gas/arm/archv6t2-bad.s: New error case.
>>>>          * testsuite/gas/arm/archv6t2-bad.l: New error match.
>>>>          * testsuite/gas/arm/archv6t2.s: New testcase.
>>>>          * testsuite/gas/arm/archv6t2.d: New expected result.
>>>>          * testsuite/gas/arm/archv8m.s: New testcase
>>>>          * testsuite/gas/arm/archv8m-base.d: New expected result.
>>>>          * testsuite/gas/arm/archv8m-main.d: Likewise.
>>>>          * testsuite/gas/arm/archv8m-main-dsp-1.d: Likewise.
>>> this caused
>>>
>>> $ cat bug.s
>>> .syntax unified
>>> .text
>>> .arch armv7-a
>>>     mov r3,#1
>>>
>>> .arch armv4t
>>> .eabi_attribute 6,2
>>>     bx lr
>>>
>>> $ arm-none-linux-gnueabihf-as -mthumb bug.s
>>> bug.s: Assembler messages:
>>> bug.s:4: Error: invalid constant (1) after fixup
>>>
>>> previously this worked, but i'm not sure if the mix
>>> of .arch directives and .syntax unified is valid here.
>
> It looks to me the failure is caused by the second ".arch armv4t" 
> overrides the
> first ".arch armv7-a", therefore the arch feature is lowerd to armv4t in
> assembler fixup stage.  While "mov r3, #1" under thumb mode is only 
> allowed
> with ARMv6T2.
>
> This patch tightend the check from
>
>       if (fixP->fx_r_type == BFD_RELOC_ARM_T32_IMMEDIATE
>           || fixP->fx_r_type == BFD_RELOC_ARM_T32_ADD_IMM)
>
> into:
>
>       if ((fixP->fx_r_type == BFD_RELOC_ARM_T32_IMMEDIATE
>            && ARM_CPU_HAS_FEATURE (cpu_variant, arm_ext_v6t2))
>           || fixP->fx_r_type == BFD_RELOC_ARM_T32_ADD_IMM)
>
>
> thus the sequences in bug.s is not allowed.

Does .object_arch works for you? It seems you want the final object arch 
adjusted.

https://sourceware.org/ml/binutils/2006-09/msg00054.html

>
>

  reply	other threads:[~2017-01-05 14:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-01 12:21 Jiong Wang
2016-11-03 11:37 ` Nick Clifton
2017-01-05 10:45 ` Szabolcs Nagy
2017-01-05 10:49   ` Szabolcs Nagy
2017-01-05 13:59     ` Jiong Wang
2017-01-05 14:16       ` Jiong Wang [this message]
2017-02-17 14:55         ` Szabolcs Nagy
2017-01-05 14:22       ` Jan Beulich

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=039ff06e-19a5-214f-0b68-feececcea951@foss.arm.com \
    --to=jiong.wang@foss.arm.com \
    --cc=binutils@sourceware.org \
    --cc=dalias@libc.org \
    --cc=reiner@reiner-h.de \
    --cc=szabolcs.nagy@arm.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).