From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 7ABC73858D32 for ; Thu, 25 May 2023 15:56:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7ABC73858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2D374D75; Thu, 25 May 2023 08:57:32 -0700 (PDT) Received: from [10.2.78.54] (e120077-lin.cambridge.arm.com [10.2.78.54]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 96E563F762; Thu, 25 May 2023 08:56:46 -0700 (PDT) Message-ID: <57db6134-6543-0763-62de-bb70208e766f@arm.com> Date: Thu, 25 May 2023 16:56:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH] PR30437 aarch64: make RELA relocs idempotent Content-Language: en-GB To: Michael Matz Cc: binutils@sourceware.org References: <1ba7b2c7-b489-79af-3f2a-56450c86d955@arm.com> <1ed54fc8-8ba0-9106-377e-61400af6c00c@arm.com> <2856489e-2127-8ab9-4902-6b8c6ea343bd@arm.com> From: "Richard Earnshaw (lists)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3493.0 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 25/05/2023 15:12, Michael Matz via Binutils wrote: > Hello, > > On Thu, 25 May 2023, Richard Earnshaw (lists) wrote: > >> I'd be surprised if even that is totally correct. ELF permits >> relocations of a single 'place' to be chained provided that they are of >> the same type (all REL or all RELA); not that I've ever seen that done >> in practice. When this is done the addend for the second and subsequent >> relocations use the result of the previous relocation - they must be >> processed in order. Only the last relocation in a sequence writes a >> value back to the location being relocated. >> >> So really, we shouldn't need two tables, we just need to know where to >> get the addend value from at the start of a chain. > > Sort of, except ... it's not just for a chain of relocs (to the same > place) steming from a single input file, but also about the similar > situation when the same place is relocated multiple times due to 'ld -r' > or pre-existing (non-zero) section content in an input file to a final > link. In this situation it's not easily determined what's the start of a > reloc chain. > > I still agree with you that abstractly multiple howto tables shouldn't be > needed, because RELA relocs _always_ should ignore section content on > read-in, and hence the reloc routines could simply special-case the > RELA/REL distinction by just not looking at src_mask or partial_inplace > for RELA relocs. It's just that BFD isn't structured in this way. > The internal representation of relocs always has an addend, no matter if > it comes from read-in section contents or a RELA reloc, and the > information of where it came from is lost (and section content isn't > zeroed on read-in for REL relocs, when transferring the addend to the bfd > reloc structure). So, to get this all somewhat working correctly right > now multiple howto entries are necessary (or special-casing target > reloc-swap-in and swap-out routines). > > I'm totally sure, once one tries to _really_ start mixing REL and RELA > relocs in a link, at the latest when ld -r and/or other toolchains are > involved, that a heap of bugs will be uncovered :-) It shouldn't be a big problem because ELF says it's undefined if the different types of reloc target the same location. IF they're addressing different (presumed non-overlapping) locations then the ordering shouldn't matter. > > (And of course, it's always possible that REL relocations cannot always be > used to achieve idempotence even in presence of 'ld -r', in which case > RELA must be used. The aarch64 psABI thankfully even spells this out.) > There's no fundamental reason why a toolchain doing 'ld -r' can't always emit RELA format relocs, even if the input format was REL. In fact, I'd argue that really it has to in most cases as 'ld -r' destroys the information that's needed to reprocess the relocations. But I agree with you, this is all likely broken in BFD because we have no way of testing it (gas can't create multiple relocs to a single location to the best of my knowledge). R.