[PATCH v3 01/10] x86: improve handling of insns with ambiguous operand sizes

[Jan Beulich]

On 27.12.2019 10:16, Jan Beulich wrote:
> Commit b76bc5d54e ("x86: don't default variable shift count insns to
> 8-bit operand size") pointed out a very bad case, but the underlying
> problem is, as mentioned on various occasions, much larger: Silently
> selecting a (nowhere documented afaict) certain default operand size
> when there's no "sizing" suffix and no suitable register operand(s) is
> simply dangerous (for the programmer to make mistakes).
> 
> While in Intel syntax mode such mistakes already lead to an error (which
> is going to remain that way), AT&T syntax mode now gains warnings in
> such cases by default, which can be suppressed or promoted to an error
> if so desired by the programmer. Furthermore at least general purpose
> insns now consistently have a default applied (alongside the warning
> emission), rather than accepting some and refusing others.
> 
> No warnings are (as before) to be generated for "DefaultSize" insns as
> well as ones acting on selector and other fixed-width values. For
> SYSRET, however, the DefaultSize needs to be dropped - it had been
> wrongly put there in the first place, as it's unrelated to .code16gcc
> (no stack accesses involved).
> 
> As set forth as a prereq when I first mentioned this intended change a
> few years back, Linux as well as gcc have meanwhile been patched to
> avoid (emission of) ambiguous operands (and hence triggering of the new
> warning).
> 
> Note that I think that in 64-bit mode IRET and far RET would better get
> a diagnostic too, as it's reasonably likely that a suffix-less instance
> really is meant to be a 64-bit one. But I guess I better make this a
> separate follow-on patch.
> 
> Note further that floating point operations with integer operands are an
> exception for now: They continue to use short (16-bit) operands by
> default even in 32- and 64-bit modes.

I've added yet another note here: {,V}PCMPESTR{I,M} would generally also
fall into the "needs suffix for disambiguation" category, but their
64-bit forms aren't really very useful. So I guess keeping the status
quo (by retaining their IgnoreSize attributes) is better than demanding
people to add suffixes there.

Jan