This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] x86: Remove movsx/movzx with 16/32-bit memory operand from AT&T syntax
On 12.02.2020 04:19, H.J. Lu wrote:
> AT&T syntax requires suffix to specify memory operand size. Since
> movsx and movzx can have different memory operand sizes with the same
> destination register, this patch removes movsx and movzx with 16/32-bit
> memory operand from AT&T syntax. Now movzx and movsx with incorrect
> suffix and register are error in AT&T syntax.
Before we discuss this patch in detail, I think we need to come
to an agreement what is and what is not meant to be permitted.
My position of this is shown by the final shape of the new
tests that the series at the root of this thread first adds and
then adjusts. It was for this very reason why I had asked that
you please point out specifically against the two patches you
put under question what you think is wrong once those patches
would be in place.
What you say above makes no sense to me at all: Why would you
remove support for something that's supposed to work?
You know my underlying thinking - things should be as
consistent as possible. What you do here moves us farther
away from consistency. This is demonstrated by both increasing
the number of templates (whereas my proposed patch shrinks
them) as well as ...
> --- a/gas/config/tc-i386.c
> +++ b/gas/config/tc-i386.c
> @@ -4395,7 +4395,9 @@ md_assemble (char *line)
> && intel_syntax)
> as_bad (_("ambiguous operand size for `%s'"), i.tm.name);
>
> - i.suffix = 0;
> + /* movzx and movsx only allow the 'b' suffix in AT&T syntax. */
> + if (i.suffix == BYTE_MNEM_SUFFIX || intel_syntax)
> + i.suffix = 0;
> }
... a change like this. Recall that mine does away with this
rather arbitrary check here altogether, putting in place
less arbitrary (imo) checks/adjustments elsewhere instead?
While secondary, I also get the impression that, other than
my patch again, and in contrast to the adjustments recently
done for MOVSXD, the (not very useful) form having 16-bit
source and destination doesn't get supported by this change.
Which underlines what I've said initially: There first of
all needs to be a clear (and consistent) picture of what is
or is not supposed to work.
Jan