This is the mail archive of the 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 14.08.2019 01:30,  H.J. Lu  wrote:
On Mon, Aug 12, 2019 at 1:21 AM Jan Beulich <> 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)


         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
3. Default memory size isn't consistent.

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

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.


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