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

[Jan Beulich <jbeulich at suse dot com>]

On 14.08.2019 01:30,  H.J. Lu  wrote:
> On Mon, Aug 12, 2019 at 1:21 AM Jan Beulich <jbeulich@suse.com> wrote:
> > On 10.08.2019 01:10,  H.J. Lu  wrote:
> > >   From assembly program and debug perspective, a suffix is very useful
> > > when there may be different memory operand sizes.   Allowing more
> > > cases without suffix isn't helping here.  We need a strong reason to
> > > do that.
> >
> > I've given this very simple and (imo) pretty strong reason:
> > Consistency. Programmers ought to be able to deduce from observed
> > behavior on one insn how another, similar insns is going to be
> > treated by the assembler. Once again, simply compare un-patched
> > gas behavior for
> >
> >          add     $1, (%eax)
> >          bt      $1, (%eax)
> >
> > vs
> >
> >          add     $0x89, (%eax)
> >          shl     $1, (%eax)
> >          shl     $2, (%eax)
> >          shl     %cl, (%eax)
> >
> > This is simply unacceptable.
> >
> > Having put together this series I think I've managed to (mostly)
> > understand why this is, but the pattern behind it has absolutely
> > nothing to do with how programmers should write their code.
> >
> > I wouldn't, btw., mind if we uniformly rejected ambiguous insns,
> > but it was my understanding from the original discussion (a few
> > years back) that you wouldn't accept this.
> >
> > In any event, may I remind you that during said earlier discussion
> > you had agreed to the underlying concept, including setting forth
> > acceptance criteria? I view it as entirely unreasonable that
> > you've made me invest quite a bit of time to fulfill those
> > criteria (and to get the patch, which as you can see has ended up
> > as a series) into a shape where the result is actually making
> > sense, just to find now that all of the sudden you mean to block
> > all of this work.
>
> My concerns are
>
> 1. AT&T syntax uses suffix for memory operand size.
> 2. Many instructions without suffix are accepted with default memory
> size.
> 3. Default memory size isn't consistent.

Is it? Afaict what's inconsistent is whether insns are accepted without
suffix.

> 4. Programmers have lived with inconsistency for years.

That's no excuse to keep things like this.

> I'd like to require suffix when memory sizes are possible.  It certainly
> won't happen.  But adding more default memory size doesn't help
> AT&T syntax.

I've said so before: I'd be happy to switch to a mode where the lack
of suffix is an error when otherwise there's an ambiguity (as is
already the case in Intel syntax mode). But considering prior behavior
this seems rather harsh, hence emitting warnings (and doing so
consistently) seems the better initial step. Switching these to being
errors instead could be considered a few releases later.

Jan