[PATCH] x86: Don't display eiz with no scale

[Jan Beulich]

On 21.07.2020 13:29, H.J. Lu wrote:
> On Tue, Jul 21, 2020 at 2:40 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 15.07.2020 15:57, H.J. Lu wrote:
>>> On Tue, Jul 14, 2020 at 11:14 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 14.07.2020 18:54, H.J. Lu wrote:
>>>>> On Tue, Jul 14, 2020 at 5:55 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>
>>>>>> On Tue, Jul 14, 2020 at 5:51 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>
>>>>>>> On 14.07.2020 14:43, H.J. Lu wrote:
>>>>>>>> On Mon, Jul 13, 2020 at 11:12 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>> Nevertheless, I've meanwhile thought of a (contrived) case that was
>>>>>>>>> broken with the code present:
>>>>>>>>>
>>>>>>>>>         addr32 mov $0x89abcdef, %rax
>>>>>>>>>
>>>>>>>>> would have got the immediate sign-extended from 32 to 64 bits.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I opened:
>>>>>>>>
>>>>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=26237
>>>>>>>>
>>>>>>>> There are multiple issues.
>>>>>>>
>>>>>>> Hmm, the former two lines there look correct to me, while the latter
>>>>>>> two lines look to have been translated with a gas that didn't have
>>>>>>> yesterday's change yet. IOW - I'm somewhat confused.
>>>>>>
>>>>>> The bug is against binutils 2.35, not master.
>>>>>>
>>>>>
>>>>> Here is the patch for master branch.
>>>>
>>>> Ah, so your issue was just with disassembly. Yet then why not go a step
>>>> further and (at least in 64-bit mode) print
>>>>
>>>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef
>>>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211
>>>>
>>>> instead of
>>>>
>>>> [       ]*[a-f0-9]+:    67 48 89 1c 25 ef cd ab 89      mov[ ]+%rbx,0x89abcdef\(,%eiz,1\)
>>>> [       ]*[a-f0-9]+:    67 89 04 25 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,1\)
>>>>
>>>> and keep the () part only for
>>>>
>>>> [       ]*[a-f0-9]+:    67 89 04 65 11 22 33 ff         mov[ ]+%eax,0xff332211\(,%eiz,2\)
>>>>
>>>> , as there's no SIB-less way to express a base-and-index-less address?
>>>>
>>>
>>> Done.
>>>
>>> I am checking in this.
>>
>> Having only now noticed the collision with my change to
>> evex-no-scale-64.d, I wonder whether we want to revert your change,
>> and hence whether my underlying suggestion was a bad one: There's
>> now no sign left that these insns use 32-bit address mode. The
>> alternative would be to ensure that an addr32 prefix gets emitted.
>> I'd personally favor this alternative, but I could live with the
>> revert. (When making the suggestion I didn't realize this is a
>> 32-bit-addressing-specific output mode.)
>>
> 
> Can you revert it for me?

Done.

Jan