This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 06/10] x86: improve handling of insns with ambiguous operand sizes


On Tue, Aug 6, 2019 at 1:26 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Aug 6, 2019 at 7:27 AM Jan Beulich <jbeulich@suse.com> 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).
>
> If there may be an ambiguity, a size suffix can be used.  Assembler isn't
> responsible for programmer's errors.
>
> > 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
>
> This punishes the perfectly good assembly sources.
>
> > 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. The set of
> > "DefaultSize" one gets slightly widened for the purposes here.
>
> Widen the default size set avoids generate warnings.  It sounds to
> me these warnings isn't really necessary.
>
> > 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 emitting of ambiguous operands (and hence triggering of the new
> > warning).
> >
> > Note 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.
> >

Instruction suffix has been an issue with AT&T syntax.  But improvements
shouldn't assemble current working assembly sources cleanly.  It is reasonable
to require that programmers should know what they are doing.  We should

1.  Require suffix if there may be ambiguity.
2.  Generate a warning if needed under a new option, (-mambiguity-check=?).
3.  Document the default operand size for AT&T syntax if there may be ambiguity.

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]