This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 06/10] x86: improve handling of insns with ambiguous operand sizes
On 06.08.2019 22:26, H.J. Lu 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.
But it should, as far as possible, aid him. Even more so when such
aid so far has been there in some cases, but not in others.
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.
What is "perfectly good" here? The lack of a disambiguating suffix is
is definitely not "perfectly good".
Furthermore - if you really mean to object to warnings in such cases,
then you should have said so when I first announced the plan for this
change. All you demanded back then was that gcc and Linux be adjusted
up front to not trigger any such new warnings (and you had offered to
take care of glibc yourself).
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.
I'm afraid I don't understand this reply of yours. As per the original
discussion a few years back the warnings are to be introduced, and
hence they want to be suppressed in sufficiently unambiguous cases
(like the branches getting DefaultSize added here, or the MOVSX/MOVSX
insns with 16-bit destinations in the later patch).
Jan