From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 08493384F6E2 for ; Fri, 18 Nov 2022 04:59:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 08493384F6E2 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-pl1-x62d.google.com with SMTP id 4so3630418pli.0 for ; Thu, 17 Nov 2022 20:59:30 -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=7LKEiQL0QRegr3hQWrShWt7XqDE5VG/imA0d08TaLIk=; b=nspm6cMhy2k6XJDP7krBX76R8nBnEP4DqJZHDk0wxj7GXovktmOf23pzWPnz8uXQjp FQsngK4Df1mvc+kpN4YhORqrX+Lx58eorbDdZQ01zCW6CQbaghtOmmpSmNa8yNRIpioH c0BoXy0p2DxU7qrcxpGMb1JtcvKhKAn0h6O/f+7djTL6HMyPjlVIxIR2Py0t8cThF2XV gFb8nP+3LXXCaUxsNMwHaZULXjc4eoK9vKRGj3U/yf4fQAvAH6khPJxLAZbUOJr1aKsr QxLgp6M817svQoja796ZjhlSc/QZyKwW3foDq2S7sF4U49cpZRLG8tkxbInlRLpf2vyY fh3Q== 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=7LKEiQL0QRegr3hQWrShWt7XqDE5VG/imA0d08TaLIk=; b=EL0g7siASOqvU7FnA6kkWKFbwtiApos+6/FBxiXXneouw9SuhDtM9HYO7R03kunLR/ psm7dr5gta8zlMjFTb0zdQZkEZ9+wbuHdzSi5+YZV21r1aBeHyAfNPRIEa19qmrAWmbV Le1LgmmuAwvIK7Cf6eJPn+sAg/F7EITBLVZHiscfx8FkyWi6yQF6SScpb2Rj0DE+DFOp 0PlW/i66K+1z5CnRO1wh+FcB9YnehX/xreAZ10b+3MAJkDTtJAixuX4H9oziIDy8AqzE b5dgDkmLKD8IHzhoI1BRH91+IiF7+MZGfH31ynOXNgcHBfeXwzGKJcLCzrFZnF+h9uVZ hprg== X-Gm-Message-State: ANoB5pnduYFrj2pMZcHgID0diOIfxiU3+3g5IKrdJMmEZUckaIR1XapM SSn4y7K4xMHESNBpKmBKLELlzQ== X-Google-Smtp-Source: AA0mqf6bRPnQZVtwSOA8+aHKXNMV9ixKNnh0Vn/aYtdXqFpgzt9aVkhp/wM1CSqUSKWDC/auEobTZQ== X-Received: by 2002:a17:90a:a012:b0:20d:7c09:c92d with SMTP id q18-20020a17090aa01200b0020d7c09c92dmr6019777pjp.95.1668747569930; Thu, 17 Nov 2022 20:59:29 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id q17-20020a170902dad100b001886863c6absm2426094plx.97.2022.11.17.20.59.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Nov 2022 20:59:29 -0800 (PST) Date: Thu, 17 Nov 2022 20:59:29 -0800 (PST) X-Google-Original-Date: Thu, 17 Nov 2022 20:59:24 PST (-0800) Subject: Re:[PATCH 1/1] RISC-V: Make R_RISCV_SUB6 conforms to riscv abi standard In-Reply-To: <2bb257a9.2114e.18467527bf0.Coremail.shihua@iscas.ac.cn> CC: zengxiao@eswincomputing.com, binutils@sourceware.org From: Palmer Dabbelt To: shihua@iscas.ac.cn 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=-10.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,GIT_PATCH_0,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 Fri, 11 Nov 2022 07:32:49 PST (-0800), shihua@iscas.ac.cn wrote: > LGTM,and I think it would be better to have a test example. > > > > > >> From: zengxiao >> >> This patch makes R_RISCV_SUB6 conforms to riscv abi standard. >> R_RISCV_SUB6 only the lower 6 bits of the code are valid. >> The proposed specification which can be found in 8.5. Relocations of, >> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/v1.0-rc4/riscv-abi.pdf >> >> bfd/ChangeLog: >> >> * elfxx-riscv.c (riscv_elf_add_sub_reloc): Take the lower >> 6 bits as the significant bit >> >> reviewed-by: gaofei@eswincomputing.com >> jinyanjiang@eswincomputing.com Is this trying to say that both of you reviewed it? >> Signed-off-by: zengxiao >> --- >> bfd/elfxx-riscv.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c >> index f0c91cc97f7..0fbfedd17fe 100644 >> --- a/bfd/elfxx-riscv.c >> +++ b/bfd/elfxx-riscv.c >> @@ -994,6 +994,13 @@ riscv_elf_add_sub_reloc (bfd *abfd, >> relocation = old_value + relocation; >> break; >> case R_RISCV_SUB6: >> + { >> + bfd_vma six_bit_valid_value = old_value & howto->dst_mask; >> + six_bit_valid_value -= relocation; >> + relocation = (six_bit_valid_value & howto->dst_mask) | >> + (old_value & ~howto->dst_mask); >> + } >> + break; Unless I'm missing something here, this just just silently truncates the relocation to 6 bits because the range check still assumes an 8-bit relocation range. I'm not sure if there's a way to massage the howto entry to make bfd_reloc_offset_in_range() understand this is a 6-bit relocation, if that's not viable then we should just check for the overflow here and return bfd_reloc_outofrange. That also means there should be at least two test cases, on within range and one outside of it. >> case R_RISCV_SUB8: >> case R_RISCV_SUB16: >> case R_RISCV_SUB32: >> -- >> 2.34.1