From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id 54183384781A for ; Fri, 18 Mar 2022 12:03:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 54183384781A Received: by mail-pj1-x102b.google.com with SMTP id m11-20020a17090a7f8b00b001beef6143a8so8115760pjl.4 for ; Fri, 18 Mar 2022 05:03:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1Ldd+1Nv5pWSUwhDfRVM2N+cKu22+Jcs4QfRZTVUX8A=; b=N9CMOgGlDEOwe47iMlP/z+r0IbO8TyznMT9i3rMVxhzZQ9TvYeUI48bDU07Hhkp06z X7OQ4WFF2P9tUrXyBDJqLInU/hVl6uYu4ajm2Kz0A0vfpvrA8qQWvHakrcT3IqjQO1Rx g4adoYx/wuNsvFeyHgzgo1LtHrxdJKTfDD1TfkervGcvDiDDjtqYcv50SuDlsxWRXSH3 oWU9rWqUols6Bfhshn8CrHfxSBzjTtbVzPh6CLLRc/GSwx5PWUTjONYeb7aEUlrS3iec SVJX9GYY/TBwJjjy7Ppp6fw14WPWdxn5U9hzBhyl92f9g0x2d9rwGjLZNYVFoiwxNSo5 7YBw== X-Gm-Message-State: AOAM531r3eYHkICNWswo2B4WkTBkwuICd0NJzE44mS+FYGyAXE+vEViY x6oCoqplVL64SwwNEMLuyPuqCQDK5Mk= X-Google-Smtp-Source: ABdhPJzR/FQuoFMCV3m8LXhNrXbEI5Y2QnmtEsNl1Qs57GTWVPOJeH8ViT23ZwrRO5mwbt215beFDA== X-Received: by 2002:a17:902:758f:b0:14f:b5ee:cc5a with SMTP id j15-20020a170902758f00b0014fb5eecc5amr9491100pll.43.1647604990922; Fri, 18 Mar 2022 05:03:10 -0700 (PDT) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id k15-20020a63ab4f000000b00381eef69bfbsm6675091pgp.3.2022.03.18.05.03.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Mar 2022 05:03:09 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id C7787114007D; Fri, 18 Mar 2022 22:33:06 +1030 (ACDT) Date: Fri, 18 Mar 2022 22:33:06 +1030 From: Alan Modra To: Jan Beulich Cc: binutils@sourceware.org Subject: Re: PR28977 tc-i386.c internal error in parse_register Message-ID: References: <2da05d25-9304-bb71-1fee-9370a0171331@suse.com> <2614e201-d2a0-6e68-23f7-ea4c14700df0@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2614e201-d2a0-6e68-23f7-ea4c14700df0@suse.com> X-Spam-Status: No, score=-3031.7 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 18 Mar 2022 12:03:14 -0000 On Fri, Mar 18, 2022 at 10:39:42AM +0100, Jan Beulich wrote: > On 18.03.2022 08:32, Alan Modra wrote: > > My testcase was a little tidier but still gives: > > > > mad.s: Error: invalid operands (*GAS `reg' section* and *GAS `reg' section* sections) for `%' when setting `s' > > That's only with your change in place, I assume? Yes. > > The aim of the patch is to stop an abort *before* we decide the > > expression is invalid. i386 parse_register was being called via > > md_parse_name in gas/expr.c:operand. > > It still feels like your change is merely hiding a problem elsewhere. If you think the patch is wrong, please feel free to revert it. Since we are getting into this discussion, I guess I should have asked permission. I don't doubt there are problems elsewhere, but I have some experience tweaking the expression evaluation code (as do you) and don't want to go down that rabbit hole for the sake of correcting the ssegment in erroneous expressions. I most definitely do not want to spend a large amount of my time fixing things that never occur in real assembly source, as opposed to the ridiculuous stuff fed to gas by fuzzers. > Going from your example (and observing where the abort actually is > reported) I added a 3rd instance of x=s. Then the abort continues to > be reported on the 2nd instance. If things were working consistently, > I would expect it to happen either on the first instance or at the > end of the file (in this latter case the location reported would > simply be bogus). Oh yes, I noticed the same. Just one instance of x=s doesn't hit the problem either. There were rather a lot more duplicated assignments in the original 17k of fuzzer garbage, and the symbol name wasn't a nice "x"! > I think the original know(e->X_op == O_register) was actually quite > appropriate when seeing a reg_section symbol come in. No reg_section > symbols violating this should ever be constructed, at least not for > x86. Might be difficult to enforce if forward references are allowed. Heh, if you really want to get your teeth into this, try this one: b=a a=%rax xor b,%rax > There might be architectures where such makes sense, albeit > code like this in expr.c: > > else if (mode != expr_defer && segment == reg_section) > { > expressionP->X_op = O_register; > expressionP->X_add_number = S_GET_VALUE (symbolP); > } > > makes me think such should never be put into existence. I seem to > have a vague recollection of, very long ago, having discussed with > you already the question of too little use of expr_section in the > course of expression evaluation (without any actual outcome as far > as changes to the code). > > Jan -- Alan Modra Australia Development Lab, IBM