This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH 05/10] x86: add tests to cover defaulting of operand sizes for ambiguous insns
- From: Jan Beulich <jbeulich at suse dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 7 Aug 2019 10:00:22 +0200
- Subject: Re: [PATCH 05/10] x86: add tests to cover defaulting of operand sizes for ambiguous insns
- References: <email@example.com> <firstname.lastname@example.org> <CAMe9rOpAaG4JnWUO4PA3iX9bvo18uWEA2=b9fLTvBOg4ApC6iQ@mail.gmail.com>
On 06.08.2019 21:56, H.J. Lu wrote:
On Tue, Aug 6, 2019 at 7:26 AM Jan Beulich <email@example.com> wrote:
I don't see anything wrong since these are just tests.
Prior to changing the logic in the assembler install tests to make sure
the present defaulting of operand sizes won't get broken. There are a
few potential anomalies pointed out by this:
- arithmetic insns (add, sub, etc) allow defaulting when their immediate
fits in (signed) 8 bits, but they fail to assemble with larger values,
The default destination is 32-bit with some 32-bit immediate operands
encoded as 8-bit.
It is extremely odd that prior to this series only some of the forms
default to 32-bit memory operands. The test cases inserted into the
new tests here by the next patch should make this oddity very obvious.
- mov, other than arithmetic insns, doesn't allow any defaulting,
- movsx/movzx default to byte sources (in AT&T mode), and their special
casing needs to be adjusted first
Does AT&T syntax support movsx/movzx mnemonic?
- bt and friends allow defaulting, while shl and friends don't,
- ambiguous AVX and AVX512 insns don't allow defaulting.
This should ultimately all become consistent (perhaps with the exception
some of the SIMD insns); respective tests will be added to the test
cases here as the issues get addressed.
AT&T syntax isn't very consistent. Improve its consistency is OK as long
as it is compatible with existing assembly codes.
Hence the introduction of these test cases ahead of any changes made.
This way it'll be clear that in the existing code that assembles fine
will continue to assemble (perhaps just with a warning) to the same
encodings. The only exception are some MOVSX/MOVZX encoding (in the
respective later patch) where what gas currently emits is clearly not
in line with everything else. And the warning emitted with those
changed encodings will tell the programmer very clearly to go look.
2019-08-XX Jan Beulich <firstname.lastname@example.org>
* testsuite/gas/i386/noreg16.d, testsuite/gas/i386/noreg16.s,
testsuite/gas/i386/noreg64.d, testsuite/gas/i386/noreg64.s: New.
* testsuite/gas/i386/i386.exp: Run new tests.
OK with clarification of commit message.
Well, I'll be happy to clarify whatever is needed, but from your reply
it's not clear (to me) what needs clarifying.
Anyway - I've noticed only now that the new test cases should also
include "NOP <mem>" forms, so I'll need to produce a v2 anyway.