From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 5B3B33858D1E for ; Mon, 9 Jan 2023 19:07:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5B3B33858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pj1-x1032.google.com with SMTP id l1-20020a17090a384100b00226f05b9595so8722166pjf.0 for ; Mon, 09 Jan 2023 11:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=i7UZLQhlc2WGB8JyyiROfluD0vsl6PceRIJSfGtfMg4=; b=U6UYjxj8o2gBdgYFISkgnme+HwWJQ2zq9wcvspGcPJaxeCq1Dh3NDOtCd5qj0P4R0Y 1WAhumcDusTjUz4JVi08CRtnSf2Noj6ItK83U4Jkj/lNgFD46ghU4g48kUWRSX0X8o8J sp0IV/JYNsyR+t5l/ti1gHT58RqPT0EBvtA6ei2edLJxKRITTznlTRQWwIkqy044j9Iy 07cVFe+luMu3Vm2TadYlfy0qWQvFkNNlB335N9lCgIrBwBOPPDFh+LsMd3Iuik1ob+cP XzXy+S3Yby/Ok1OE+EOfguXpkkbVr9Y3BbSDwdPznWgt1WZNj6qcpe+l8vdsoSKi/QrO cmug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=i7UZLQhlc2WGB8JyyiROfluD0vsl6PceRIJSfGtfMg4=; b=eOQFpJqREV/domzRtUGWkKVEwKsChpTa6UUqSFdi8Bq/N9RZo3g+RqMOoz223AlwaB xyrANFH8zKKW71j0PlyTSes31iD/At8g29Hy6nhy61aZOHY7Cp9Q3jg/aisHmmtd9qTA scrx/lvhl7f5ua/el1TGUAeJoCreyaCN79KJiMg8LOgiZDo8JLDdLFomXbJ/odLrtNDu yuqMp7g3Mh+M4xsudGxxWPOwX78G3Wjd5Rcbfo0LMhiGFeMe+1VEhHeR5EXU6h920DdI MdPCXimfvM/C95K5E3NnwS1h2zYUz6O1z6kbxp5nQcAjlNWtDUK8gjnJykioukJz4VaN y8kw== X-Gm-Message-State: AFqh2kphpDePnWKjBFWHAJamy6+LLLI35Osx2IDfJQ7xnXer194IHIHA yZcTiJUhuZCPpGMuushyo8L1Xybc/nL0rgE+ X-Google-Smtp-Source: AMrXdXsTwpo9rnvBM9/aTs53oxGnzhJ1FffYxW2/iyta3CsJHJOk4URkPy3mf51T+ySkZSt9sT6XWg== X-Received: by 2002:a17:903:28e:b0:192:a470:c6d with SMTP id j14-20020a170903028e00b00192a4700c6dmr41414878plr.41.1673291224329; Mon, 09 Jan 2023 11:07:04 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id v11-20020a170902f0cb00b00180033438a0sm6495940pla.106.2023.01.09.11.07.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Jan 2023 11:07:03 -0800 (PST) Date: Mon, 09 Jan 2023 11:07:03 -0800 (PST) X-Google-Original-Date: Mon, 09 Jan 2023 11:06:38 PST (-0800) Subject: Re: [PATCH] gas/RISC-V: adjust assembler for opcode table re-ordering In-Reply-To: CC: Andrew Waterman , Jim Wilson , nelson@rivosinc.com, Nick Clifton , binutils@sourceware.org From: Palmer Dabbelt To: jbeulich@suse.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 09 Jan 2023 09:07:06 PST (-0800), jbeulich@suse.com wrote: > On 08.01.2023 00:29, Aurelien Jarno wrote: >> On 2023-01-06 13:34, Jan Beulich via Binutils wrote: >>> PR gas/29940 >>> >>> With the single-operand JAL entry now sitting ahead of the two-operand >>> one, the parsing of a two-operand insn would first try to parse an 'a'- >>> style operand, resulting in the insertion of bogus (and otherwise >>> unused) undefined symbols in the symbol table, having register names. >>> Since 'a' is used as 1st operand only with J and JAL, and since JAL is >>> the only insn _also_ allowing for a register as 1st operand (and then >>> there being a 2nd one), special case this parsing aspect right there. >>> --- >>> This, of course, is fragile, but I guess such workarounds are >>> unavoidable with the chosen approach of (recurring) parsing, and with >>> register names being special only in certain contexts. >>> >>> A more generic approach, then possibly also helping performance, might >>> be to count the number of operands first, and do full parsing only when >>> the count matches that in the operand specifier string (at least when >>> there are multiple insn forms). >>> >>> The similar workaround in my_getSmallExpression() actually looks >>> suspicious to me: I expect that it would get in the way of using equates >>> "shadowing" names of GPRs. >>> >>> --- a/gas/config/tc-riscv.c >>> +++ b/gas/config/tc-riscv.c >>> @@ -3266,6 +3266,17 @@ riscv_ip (char *str, struct riscv_cl_ins >>> continue; >>> >>> case 'a': /* 20-bit PC-relative offset. */ >>> + /* Like in my_getSmallExpression() we need to avoid emitting >>> + a stray undefined symbol if the 1st JAL entry doesn't match, >>> + but the 2nd (with 2 operands) might. */ >>> + if (oparg == insn->args) >>> + { >>> + asargStart = asarg; >>> + if (reg_lookup (&asarg, RCLASS_GPR, NULL) >>> + && (*asarg == ',' || (ISSPACE (*asarg) && asarg[1] == ','))) >>> + break; >>> + asarg = asargStart; >>> + } >>> jump: >>> my_getExpression (imm_expr, asarg); >>> asarg = expr_end; >> >> Thanks for the patch. I have tested it and confirmed it fix the problem >> I reported. > > With 2.40 scheduled to be cut in less than a week, may I ask for an arch > maintainer's view here? Thanks for fixing this. I don't have any issues with what's there, but looks like I'm also getting some failures (glibc/multilib errno related stuff). I'm trying to bisect those so I can't really get a proper test up now, I'll try to do so ASAP as it's really late to have stuff broken. > Nick, to save a round trip, could you confirm (or otherwise) that this > fix is then also fine to go on the branch (after having gone into master)? > > Thanks, Jan