public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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.

  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).