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

[Jan Beulich]

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.)

Jan