From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) by sourceware.org (Postfix) with ESMTPS id 7FE2D3858CDB for ; Wed, 17 Aug 2022 19:22:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7FE2D3858CDB Received: by mail-qt1-x835.google.com with SMTP id e28so11159113qts.1 for ; Wed, 17 Aug 2022 12:22:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=DeinXmOL8rSgQm9ABoP9vyA1cfHTHeBUW8xp1Ufk7+A=; b=Knw7f0Q9QxLKolsV/TSeW60DQd0OJYFIYncms2IdSWb9GWHm4TpvGe+luL1vRYzKn+ IpLae1PfEFFvsAYo0jN1lZyEz4B2Zr/Y4V8/ZaNVyN8hds5Cp10aWRvqd8L0FiB6hZ1w TY7IbkNQRr3kFxCkCGA0Fk7OFb1S7nBAghnmoRFI0pUGbaAfOOrBQ1BYEdsDK8uYoXlB 17vZUYzV+zEXUyTBRgxzV4NwgcudAWlS9WmOZBNQ8uVcuraWXAqVxGRvg3fUh9Y5jPXU xIEmLu/zutCP0zbo9lQgH5BSjTd/YOXynlvkvHSuB+RGsCRsXtbtsQK8oZ8SuFcBvi1J 8pqw== X-Gm-Message-State: ACgBeo2DuJoONAe9GHbvJo/mHzH57ipsIKdNDwo+7bfE9BK3tUQec85g b6+1dZx8ruemY8r2j4LTbDmgzyc4VZ3RuaV9FHRjj/FH X-Google-Smtp-Source: AA6agR7ohLR34UrzxouMHZRe/lgnDgq2SiqIcmi3XPheCzt8vIfQwFm04sAK6ZV0YSVMAucF6asGrZ0FSwQaBQ9RjHM= X-Received: by 2002:a05:622a:205:b0:343:282:3d0e with SMTP id b5-20020a05622a020500b0034302823d0emr24139857qtx.436.1660764143808; Wed, 17 Aug 2022 12:22:23 -0700 (PDT) MIME-Version: 1.0 References: <32216291-fd1f-4579-87de-d24cb7190894@suse.com> <8e4dc724-3516-6ec7-5a6b-70ed70e3e237@suse.com> In-Reply-To: <8e4dc724-3516-6ec7-5a6b-70ed70e3e237@suse.com> From: "H.J. Lu" Date: Wed, 17 Aug 2022 12:21:48 -0700 Message-ID: Subject: Re: [PATCH 3/7] x86: move / quiesce pre-386 non-16-bit warning To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2022 19:22:27 -0000 On Tue, Aug 16, 2022 at 12:31 AM Jan Beulich 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.