From: "H.J. Lu" <hjl.tools@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: [PATCH 3/7] x86: move / quiesce pre-386 non-16-bit warning
Date: Wed, 17 Aug 2022 12:21:48 -0700 [thread overview]
Message-ID: <CAMe9rOqLfLA3HHz8UCw-qRQLceTQAB+GGHxuzP=Noxg_wmcDww@mail.gmail.com> (raw)
In-Reply-To: <8e4dc724-3516-6ec7-5a6b-70ed70e3e237@suse.com>
On Tue, Aug 16, 2022 at 12:31 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> Emitting this warning for every insn, including ones having actual
> errors, is annoying. Introduce a boolean variable to emit the warning
> just once on the first insn after .arch may have changed the things, and
> move the warning to output_insn(). (I didn't want to go as far as
> checking whether the .arch actually turned off the i386 bit, but doing
> so would be an option.)
> ---
> Otoh I wonder whether switching to a pre-386 architecture shouldn't
> automatically move to CODE_16BIT: Us emitting operand- or address-size
> prefixes violates the architecture specification. Alternatively we
> could outright reject such .arch directives when not already in 16-bit
> mode.
>
> I've left the message text unaltered, albeit I think "addressing mode"
> is particularly misleading for instructions without memory operands (nor
> any other address-size affected aspect, like in e.g. JCXZ).
>
> Originally I thought the warning may get in the way of work done in
> subsequent patches, but I think I've convinced myself that all affected
> insns are post-286 and hence wouldn't yield CPU_FLAGS_PERFECT_MATCH.
>
> --- a/gas/config/tc-i386.c
> +++ b/gas/config/tc-i386.c
> @@ -765,6 +765,9 @@ int optimize_align_code = 1;
> /* Non-zero to quieten some warnings. */
> static int quiet_warnings = 0;
>
> +/* Guard to avoid repeated warnings about non-16-bit code on 16-bit CPUs. */
> +static bool pre_386_16bit_warned;
> +
> /* CPU name. */
> static const char *cpu_arch_name = NULL;
> static char *cpu_sub_arch_name = NULL;
> @@ -2809,6 +2812,7 @@ set_cpu_arch (int dummy ATTRIBUTE_UNUSED
> cpu_arch_tune = cpu_arch_isa;
> cpu_arch_tune_flags = cpu_arch_isa_flags;
> }
> + pre_386_16bit_warned = false;
> break;
> }
>
> @@ -5486,12 +5490,7 @@ parse_insn (char *line, char *mnemonic)
> {
> supported |= cpu_flags_match (t);
> if (supported == CPU_FLAGS_PERFECT_MATCH)
> - {
> - if (!cpu_arch_flags.bitfield.cpui386 && (flag_code != CODE_16BIT))
> - as_warn (_("use .code16 to ensure correct addressing mode"));
> -
> - return l;
> - }
> + return l;
> }
>
> if (!(supported & CPU_FLAGS_64BIT_MATCH))
> @@ -9491,6 +9490,13 @@ output_insn (void)
> fragP->tc_frag_data.max_bytes = max_branch_padding_size;
> }
>
> + if (!cpu_arch_flags.bitfield.cpui386 && (flag_code != CODE_16BIT)
> + && !pre_386_16bit_warned)
> + {
> + as_warn (_("use .code16 to ensure correct addressing mode"));
> + pre_386_16bit_warned = true;
> + }
> +
> /* Output jumps. */
> if (i.tm.opcode_modifier.jump == JUMP)
> output_branch ();
>
OK.
Thanks.
--
H.J.
next prev parent reply other threads:[~2022-08-17 19:22 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-16 7:27 [PATCH 0/7] x86: suffix handling changes Jan Beulich
2022-08-16 7:30 ` [PATCH 1/7] x86/Intel: restrict suffix derivation Jan Beulich
2022-08-17 19:19 ` H.J. Lu
2022-08-18 6:07 ` Jan Beulich
2022-08-18 14:46 ` H.J. Lu
2022-08-19 8:19 ` Jan Beulich
2022-08-19 14:23 ` H.J. Lu
2022-08-19 14:49 ` Jan Beulich
2022-08-19 17:00 ` H.J. Lu
2022-08-22 9:34 ` Jan Beulich
2022-08-22 14:38 ` H.J. Lu
2022-08-16 7:30 ` [PATCH 2/7] x86: insert "no error" enumerator in i386_error enumeration Jan Beulich
2022-08-17 19:19 ` H.J. Lu
2022-08-16 7:31 ` [PATCH 3/7] x86: move / quiesce pre-386 non-16-bit warning Jan Beulich
2022-08-17 19:21 ` H.J. Lu [this message]
2022-08-18 7:21 ` Jan Beulich
2022-08-18 15:30 ` H.J. Lu
2022-08-19 6:13 ` Jan Beulich
2022-08-19 14:18 ` H.J. Lu
2022-08-16 7:32 ` [PATCH 4/7] x86: improve match_template()'s diagnostics Jan Beulich
2022-08-17 20:24 ` H.J. Lu
2022-08-18 6:14 ` Jan Beulich
2022-08-18 14:51 ` H.J. Lu
2022-08-16 7:32 ` [PATCH 5/7] x86: re-work insn/suffix recognition Jan Beulich
2022-08-17 20:29 ` H.J. Lu
2022-08-18 6:24 ` Jan Beulich
2022-08-18 15:14 ` H.J. Lu
2022-08-19 8:28 ` Jan Beulich
2022-08-23 2:00 ` H.J. Lu
2022-08-26 9:26 ` Jan Beulich
2022-08-26 18:46 ` H.J. Lu
2022-09-06 6:40 ` Jan Beulich
2022-09-06 21:53 ` H.J. Lu
2022-09-07 7:17 ` Jan Beulich
2022-09-26 23:52 ` H.J. Lu
2022-09-28 12:49 ` Jan Beulich
2022-09-28 19:33 ` H.J. Lu
2022-09-29 8:08 ` Jan Beulich
2022-09-29 16:00 ` H.J. Lu
2022-09-29 16:06 ` Jan Beulich
2022-09-29 16:20 ` H.J. Lu
2022-08-16 7:33 ` [PATCH 6/7] x86-64: further re-work insn/suffix recognition to also cover MOVSL Jan Beulich
2022-08-16 7:34 ` [PATCH 7/7] ix86: don't recognize/derive Q suffix in the common case Jan Beulich
2022-08-17 20:36 ` H.J. Lu
2022-08-18 6:29 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMe9rOqLfLA3HHz8UCw-qRQLceTQAB+GGHxuzP=Noxg_wmcDww@mail.gmail.com' \
--to=hjl.tools@gmail.com \
--cc=binutils@sourceware.org \
--cc=jbeulich@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).