From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 1932A388451F for ; Fri, 18 Mar 2022 07:32:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1932A388451F Received: by mail-pl1-x62c.google.com with SMTP id w8so6358438pll.10 for ; Fri, 18 Mar 2022 00:32:08 -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:content-transfer-encoding :in-reply-to; bh=ODbyq6Ev+PjRKnKe/D06+FtRXPXdA4KEJlfcqvCxMls=; b=cqUjWJfsYMNSZHJhOYqRdNwhh6P8OtPsg5QTn2Evl6KC5+8OSznTS/L+muAhWmpjzY QMiwRVOr+ySlUkGmMZOftXUyCoGlna2Jzc/SMnjmoFWnD1ZpS/bd3tG07fI9WftbUsWC v0MR49CJyZumV158jX8WZ2EJWOHRztL1/IzqfZZrCT0fSHwN12yvivhXDim2m1S92VwW EV33KlwyxQggx5kTbaU+jNKnT1XBfK9UWH1hLxjFlDNd0/VYOd1aEB6TdqO1SVN60d81 lU/GC3P14O5oEwJmfmNItEnpaR/0v3X3erfGqhPbIGu1sZmNOXPAze2HK+5EkS5hBMtZ JhtA== X-Gm-Message-State: AOAM530VXGvwt+LZFv4YRGRISPdPb938SJhsXZ4qHzI0mrn2PmHc8z5a qzNWA7QcDRnbQCZFuuDHHqUcSNgFjOU= X-Google-Smtp-Source: ABdhPJwZdUTbp09AmOmJfD34y9Oi3VR+Ledi+1DYiw6kBHv5tsbxu5wEfOaD0likEGcpUlezjfQGuw== X-Received: by 2002:a17:902:ef49:b0:153:bb43:53eb with SMTP id e9-20020a170902ef4900b00153bb4353ebmr8455514plx.103.1647588726852; Fri, 18 Mar 2022 00:32:06 -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 f30-20020a63755e000000b00381f6b7ef30sm5821575pgn.54.2022.03.18.00.32.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Mar 2022 00:32:06 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id E745511403FE; Fri, 18 Mar 2022 18:02:02 +1030 (ACDT) Date: Fri, 18 Mar 2022 18:02:02 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <2da05d25-9304-bb71-1fee-9370a0171331@suse.com> X-Spam-Status: No, score=-3030.2 required=5.0 tests=BAYES_00, BODY_8BITS, 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 07:32:09 -0000 On Fri, Mar 18, 2022 at 08:12:46AM +0100, Jan Beulich wrote: > On 18.03.2022 07:56, Alan Modra via Binutils wrote: > > PR 28977 > > * config/tc-i386.c (parse_register): Handle X_op not O_register > > as for a non-reg_section symbol. Simplify array bounds check. >=20 > Hmm, isn't it that ... >=20 > > --- a/gas/config/tc-i386.c > > +++ b/gas/config/tc-i386.c > > @@ -12952,17 +12952,18 @@ parse_register (char *reg_string, char **end_= op) > > { >=20 > ... the if() right outside of context here is pointing at the actual > problem? Why would "s=3D%rdx % %rcx" result in a reg_section expression? > Imo this clearly ought to be expr_section. Perhaps, but we are off in the weeds anyway. The original fuzzer input had a completely crazy expression for "s". s=3D%ymm5%%%!%%%%!%%%%%%%=1D%%%%%%%%%%%%%%=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD= =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD%%%%%%%%%%%%%%%%%%%%%%%%= %%%%%%%%%%%%%%!%ebp%%%%%%%%%%%%%%%%%%M%%%%%%[s<=EF=BF=BD=EF=BF=BD%[s<=EF=BF= =BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD%%%%%=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD=EF=BF=BD=EF=BF=BD/+=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD%%%%[s<= =EF=BF=BD=EF=BF=BD%[s<=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD%%%%'%%%= %%%%%%%%%%%%%;%%%%%%!%%%%!%%%%%%%%%%%%%#NO 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' 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. --=20 Alan Modra Australia Development Lab, IBM