From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com [IPv6:2001:4860:4864:20::2b]) by sourceware.org (Postfix) with ESMTPS id 282173858D1E for ; Wed, 15 Feb 2023 08:48:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 282173858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-15f97c478a8so22073826fac.13 for ; Wed, 15 Feb 2023 00:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OwDmH4sfCJngmaV61HFCTWjHge+Htl29kT717VLlW3E=; b=Vjg+CjIa+HoMz/pLcC2occGL44wFlQxz9jyJ0NSyWvqNEtbLLcdS35eippZyy6be2Q 8nBXUBOu+QPqFl8z/F2wLHhSQ71feYhSord+NU9KF1CpmWSQ/lkGWx2hQ9jRWBbG0ZYx F/KHs4Shk8tUIxf5V/IVJGuTlq6hnj0eHPrKkYtUGQG47Atl0yuOmWtEY0oZ6W+2RkTw XQabkA7bC8pdDlYmXRbjTGIiHXDNOXRJRMCelw2EwG+MPPMf+gg6TxpNv+6ctU9pYc9Y WltQDFOQtJ5LYb217jr9TAhyiG0llCEZFYGN453fJe8wQDJ4+wwPcTOcxPu1fThOHs/A JtOA== 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:subject:date:message-id :reply-to; bh=OwDmH4sfCJngmaV61HFCTWjHge+Htl29kT717VLlW3E=; b=CiZb90M15JJH6c2UYpEzF3Z36nDA1elqxkEwuAxT3Y/q/U6KInKLZPI9THWEUdS0of +CAVuS6Mk/r/39nJaegXPOs/7TvG0LwNYbW/KiKoGWM0T8ny+UlL98gNawZP5Gdf9s+M NCdlMLYORUGrO6CtUi/0LIbuENZZC07AU08/eaAaKSTL/Z6q7biWaO02Gvu73js48OtN S9DcYLDlF21g2lafor6JGtAZhTGhfNK+hY4uW7c5jPaLjYQl0YNtRzTNfQMSCEP3QGBs CwJh3/tm0z4C5F4xhEIa1GKyzuqTDaPWloz5kef5sZTyRTinpICmD2NpNkushC4hceYx UpRQ== X-Gm-Message-State: AO0yUKVkLOyEEaAEPgcpWYeUBKwH/+VVBepMHlCiG7oYRDUcisD38Vws fhZNKdMug4avrwic/x5LuvfsZDBT6tj+jw8+wwMPuQ== X-Google-Smtp-Source: AK7set8Nq+H4AVMkrURYl3V9wwmAqVC9lt5eV6ErIi3vf/HWsAQ1k9txGeYbmwIl1DCLtjPXvnzn/Bq58yG0ZMx5hXE= X-Received: by 2002:a05:6870:1298:b0:16e:58a6:acb with SMTP id 24-20020a056870129800b0016e58a60acbmr71506oal.244.1676450919675; Wed, 15 Feb 2023 00:48:39 -0800 (PST) MIME-Version: 1.0 References: <2df3478a-3cd9-d7b5-670e-60683ae3066e@suse.com> <3bb126f6-5bf1-dab0-f540-25c386b9507e@suse.com> In-Reply-To: From: Nelson Chu Date: Wed, 15 Feb 2023 16:48:28 +0800 Message-ID: Subject: Re: [PATCH 2/2] RISC-V: adjust logic to avoid register name symbols To: Jan Beulich Cc: Binutils , Palmer Dabbelt , Andrew Waterman , Jim Wilson Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.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: Thanks for the detailed clarify :-) A quick update, I just use riscv-gnu-toolchain to build a linux toolchain with, gcc (releases/gcc-12.2.0) + binutils (master + these two patches) + glibc (release/2.37/master), and then I get some unexpected errors from gcc testsuite, which won't occurred without these patches. ========= Summary of gcc testsuite ========= | # of unexpected case / # of unique unexpected case | gcc | g++ | gfortran | rv64gc/ lp64d/ medlow | 347 / 62 | 29 / 9 | 0 / 0 | I haven't tested the elf regressions, and the whole linux regression, but it seems that there are some unexpected situations that we have not considered in this patch. Reproduce commands, 1. git clone https://github.com/riscv-collab/riscv-gnu-toolchain.git --recursive 2. need to install some tools before build, https://github.com/riscv-collab/riscv-gnu-toolchain#prerequisites 3. git checkout branches of gcc, binutils and glibc to the branches mentioned above 4. cd 5. configure --prefix=build-install --with-arch=rv64gc 6. make report-gcc-linux -j32 Thanks Nelson On Wed, Feb 15, 2023 at 4:03 PM Jan Beulich wrote: > > On 15.02.2023 04:09, Nelson Chu wrote: > > Though the logic becomes kind of complicated to me, you are more > > familiar with other targets than me, so maybe this is the right way to > > do it. Basically, the logic looks correct and fine to me, but I still > > need to run regressions in case of an accident. Just make sure that - > > 1. The deferred_sym_rootP are the symbols that have the same names as > > GPR (or FPR, VPR in the future maybe), but we still need to add them > > into the symbol table? > > Yes, with "may" inserted ahead of "need". We only need to if the probing > actually succeeds. > > > 2. Even if the expression has the same name as GPR, only > > my_getSmallExpression is possible to set exp to O_register, but > > my_getExpression won't have, so the probing_insn_operands is used to > > distinguish between them? > > Yes, albeit I find this distinction between the two functions suspicious > (and as said in a post-commit-message remark I'm also having trouble > spotting a pattern of when which of the two functions is [to be] used). > But I didn't want to affect existing behavior too much; iirc there was > at least one testcase which would break otherwise. As said elsewhere - > as a first step towards further improvements it would need settling on > what the intended behavior in various cases actually ought to be. > > As to the role of probing_insn_operands: Its two possible non-zero > values distinguish these two cases; zero vs non-zero distinguish whether > we deal with insn operands vs directive (or alike) ones. > > Jan