From patchwork Thu Oct 19 00:30:58 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tsukasa OI X-Patchwork-Id: 15581 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2010:b0:403:3b70:6f57 with SMTP id fe16csp80258vqb; Wed, 18 Oct 2023 17:31:34 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHoXy0WAPmigfaIoQYeIu3ueEj1XkICLpH3j4CrOt5xAcvc+f4NgNpd/4daONglkFJB1Nzf X-Received: by 2002:a05:6214:1bcd:b0:66d:145b:4591 with SMTP id m13-20020a0562141bcd00b0066d145b4591mr829496qvc.27.1697675493850; Wed, 18 Oct 2023 17:31:33 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1697675493; cv=pass; d=google.com; s=arc-20160816; b=WX+ISYpXtxx/N65BToSVcPujJbsB4SBq+4JZuRUiyZmoMO3IG6pApD9jYRs2tLvrJw IMeKxSV7e2OCp09UPCTsVsHPI8jFD5uPI7xvWn1jqM/PuO92YjIBHby1AzrhoHop3oH6 HrOtA4W6x5SJ6hF0vggJjCpWagfTFqFSIeioH+MpCElZ0VuLucpWSA4W4HQIwxN3Mp9i cOpA0XbPxg/c+9m9XmQoxisB60mhUAFMl1q9eioBKiPfAMAs8xsbGMbmhJU1Vl+P+z6H 37HLBcCK9KPN2w6eba2E3OPMiE3ANksDGuLg3gBPldMEn/71eZuEIxR91KuZSVUUyiEq iviQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :mime-version:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature:arc-filter:dmarc-filter:delivered-to; bh=s5x7MSAh3+8bUsIvf79AU2aniKtVNBfWMUSsFVzXD+M=; fh=Q+ZPQdyJDzJx4BfovHNTR1lP4msTSfN6TDra8V1lyf8=; b=r746pL9Mc4z8/ssy8UDwjglynFBRBL4i1IPVc5dSBJ8t32/kgeiOD0MSjdA34xA30p R9olWJ4BBs+Z4YJa5QUwYigsGtOy4SIbqzlFU5f+Pv/Fw0MYsRd1Yau5f+ZDJcZfj9V8 UvziEoslI6qcdhy+RuQqV9dxR4RJfXXEuI6irEioZog/a6LqP2U52Mw47erlDBh5z8Tw nyrFOZ2CQbZ/R9r3wWNUASgenHSZKZoCyeNTq34J3Jxyl6DQFVqkreCb+vEdcF2beqCC ESQmw34gFynOhO6aAkiuqTJSbY5qh1on9UXtPk4/cm3gjZ25dunFFNNPeEdCOdjHWK5m 9s7g== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@irq.a4lg.com header.s=2017s01 header.b=g2IRG0wc; arc=pass (i=1); spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=irq.a4lg.com Received: from server2.sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id g18-20020ac87f52000000b00419986f0f8csi792755qtk.633.2023.10.18.17.31.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Oct 2023 17:31:33 -0700 (PDT) Received-SPF: pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@irq.a4lg.com header.s=2017s01 header.b=g2IRG0wc; arc=pass (i=1); spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=irq.a4lg.com Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9BC8C3858C54 for ; Thu, 19 Oct 2023 00:31:33 +0000 (GMT) X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from mail-sender-0.a4lg.com (mail-sender.a4lg.com [153.120.152.154]) by sourceware.org (Postfix) with ESMTPS id 0CE2C3858D1E for ; Thu, 19 Oct 2023 00:31:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0CE2C3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=irq.a4lg.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=irq.a4lg.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0CE2C3858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=153.120.152.154 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697675488; cv=none; b=ejJBFiSwlvrGUjLRhsh7oB3oBXXxqZXq+D8pOlwON3dMSpyCtB9P0sAqwh/OXogryDzxKqbnbFiWPaIUPonr0LpnILKh8WNIIY4UdgisG5vggptufqymXlK2/trPy3z836Yq0ETCRfSEgZkhHbUaZ7Hd8+n47O+N9p0cPqAcvX8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697675488; c=relaxed/simple; bh=NoGGr99kbNcY5az9TIGtzm5WmUCIQqY4xrwFUa4WlAA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:Mime-Version; b=OnUew1jRfcagTrVco8RVmciaLtrvPcdBgmmoopT9S1MHe5EDL9kkUMZIoLpxACWdOceU7hAzuzYwnL/CHEd2ATn4Y78lhGjOgNqq2Cc1DQutOD+xnoNJXJ3aTB1F2ZRRmQpX4BAWehFuIYEKrRfUUfsX9ySVY6BitSvKlfuggKM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id E937E300089; Thu, 19 Oct 2023 00:31:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irq.a4lg.com; s=2017s01; t=1697675483; bh=s5x7MSAh3+8bUsIvf79AU2aniKtVNBfWMUSsFVzXD+M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: Mime-Version:Content-Transfer-Encoding; b=g2IRG0wc6Iew5fwgnUlakD9YXy4enSrQZBGofbzBjJonefm7SWO4FIUPDhk3Mb1FF 8Vl5wJI72M535mMonLV3CIPFk3wlre92KUCIBrq4NZyoihrbRWS8I9u3yZuUdJ1mBi UnCo9xmtUVz3eT6q4otp72nmtgMDz4FV6zinNGug= From: Tsukasa OI To: Tsukasa OI , Palmer Dabbelt , Andrew Waterman , Jim Wilson , Nelson Chu , Kito Cheng Cc: binutils@sourceware.org Subject: [PATCH v2 0/1] RISC-V: Strict relocation handling Date: Thu, 19 Oct 2023 00:30:58 +0000 Message-ID: In-Reply-To: References: Mime-Version: 1.0 X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, KAM_MANYTO, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: binutils-bounces+ouuuleilei=gmail.com@sourceware.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779890840815358358 X-GMAIL-MSGID: 1780141778205133348 Hi, This is the PATCH v2 of an attempt to prevent future accidents possibly caused by future relocation additions. PATCH v1: [Added in v2] 1. Internal relocations are no longer emitted from the linker even if you use ld --emit-relocs option. [Changes in v2] 1. It became a single large patch since it's harder to separate semantically (and cleanly). 2. Rejecting unknown relocs in riscv_elf_check_relocs is preserved but made simpler (no longer need to list all supported public relocations). I concluded that it was necessary (rare but valid as in FR-V) but there were a simpler way to perform the same operation. 3. Wraps querying whether the relocation is empty, clarifying that we want to reject empty relocations (minor). 4. Moves all internal relocations after R_RISCV_max. I'll describe this in detail. [Move internal relocations after R_RISCV_max] This method is suggested by Nelson and I tried. I soon noticed that simply moving internal relocations after R_RISCV_max doesn't work. It was due to the fact that handling of R_RISCV_DELETE (the only internal relocation defined relative to R_RISCV_max) was so special so that moving other relocations causes problems. Specifically, riscv_elf_relocate_section function (the function finally relocates the section) calls riscv_elf_rtype_to_howto and requires generic howto information. Yes, howto information. So my second attempt is: let riscv_elf_rtype_to_howto search through the special howto table only containing internal relocations only when required. As far as I know, the only location we need the internal relocations is in the riscv_elf_relocate_section function and new lookup_internal argument is set to true only here (I think adding this argument is the simplest because this function calls the error handler if fails and creating separate internal variant will require duplicating most of the code). ... and that was a success! Internal relocations are now all relative to R_RISCV_max and if a relocation type is added after the biggest known relocation, internal relocation type numbers are automatically increased. I found an interesting example in libctf/swap.h so I added bonus safety measure to make sure that such internal relocations are always safe to handle (relocation type numbers must fit in an 8-bit integer due to constraints in ELF32). I hope I resolved most of the issues Nelson pointed out. Sincerely, Tsukasa Tsukasa OI (1): RISC-V: Separate invalid/internal only ELF relocs bfd/elfnn-riscv.c | 40 +++++---- bfd/elfxx-riscv.c | 202 +++++++++++++++++++++++++++----------------- bfd/elfxx-riscv.h | 3 +- include/elf/riscv.h | 37 ++++++-- 4 files changed, 183 insertions(+), 99 deletions(-) base-commit: e734b3e980d8a30ea23b5640d871b59d33720ecf