x86: AT&T syntax operand size defaults

[Jan Beulich]

>>> On 16.11.17 at 00:05, <hjl.tools@gmail.com> wrote:
> On Wed, Nov 15, 2017 at 6:03 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 15.11.17 at 14:30, <hjl.tools@gmail.com> wrote:
>>> On Wed, Nov 15, 2017 at 5:05 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 15.11.17 at 13:46, <hjl.tools@gmail.com> wrote:
>>>>> On Wed, Nov 15, 2017 at 2:32 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> So there's one first fundamental roadblock here: Quite a few FPU
>>>>>> insns specify Dword|Qword|Unspecified. It seems rather obvious to me
>>>>>> that this can't be right (Unspecified should only be used when only a
>>>>>> single operand size is permitted), but even the disassembler doesn't
>>>>>> add an 's' suffix for at least the integer form ones. Would you agree
>>>>>> with fixing the disassembler independently of that other work?
>>>>>>
>>>>>
>>>>> Will this require change assembler testcase inputs?  Will the disassmebler
>>>>> output match the input?
>>>>
>>>> Well, I'd do the change in steps (in part depending on your feedback):
>>>> As a first step I'd like to fix the disassembler output, perhaps without
>>>> touching the input files (but bringing them out of sync, yet as there
>>>> are numerous examples where input and output don't fully match, I
>>>
>>> By "match", I mean I can tell assembler output is correct.  It is OK that
>>> the disassembler output isn't exactly the same assembler input.
>>
>> Oh, perhaps you've assigned stronger meaning to "exact" that I
>> had meant: Of course there can be cosmetic differences. What I
>> mean here (and what is the case elsewhere) are differences in
>> suffix between input and disassembler output.
>>
>>>> would have thought this is no problem; let me know your preference).
>>>> As a second step I'd like to change all test cases (inputs, and where
>>>> necessary outputs) where we wrongly rely on ambiguous behavior.
>>>
>>> Sure.
>>>
>>>> The 3rd and final step then would be to actually change the assembler.
>>>>
>>>> As you want me to have checked a Linux build against a such
>>>> changed assembler (and I'd imply a gcc bootstrap would be helpful to
>>>> do too, plus perhaps also using that resulting gcc for said Linux build),
>>>> this last step will take me a while. I would nevertheless hope that you
>>>> could agree with doing the first two steps earlier.
>>>
>>> Such assembler change must pass Linux kernel build for both i386 and x86-64
>>> as well as GCC and glibc build/test.
>>
>> As said, I did imply gcc and Linux. I don't think I'm in the position to
>> try glibc - I've never built that, and I wasn't planning to. You also
>> didn't make this a requirement back when I had first started this
>> thread.
> 
> You check kernel and GCC.  I will check glibc after your patch is merged.

Thanks for the offer. However, to get started at all, I first need an
opinion either way on the floating point insn aspect mentioned
earlier (and kept in context at the very top above).

Jan