From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id EDA153858D39 for ; Wed, 24 May 2023 16:03:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EDA153858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id D039421F2C; Wed, 24 May 2023 16:03:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1684944212; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zRtxP9Q0f5CF54Qu2Ow8d3E3DI+Vn1aEQ94QtAfvYHM=; b=GEkv25K/1tY7EKDhowWwC4f2lpYU09AT4fhThvIqVbIPp6IKjEpHtol/9bE1HIw0h+zb9H 2oM8Xc9cTjRx8uOGT7G6VHWT6BTTMDDuseU8lPmPL7FIH3ex5SwA5fmRy6bxkxIKOaI6UI WRZdj7ZPn6EVoA9p7BKXxgVes26ppBo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1684944212; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zRtxP9Q0f5CF54Qu2Ow8d3E3DI+Vn1aEQ94QtAfvYHM=; b=nRN0aGYD9+yolGFF22+EqV4Z/I5H9Ku9mAT65teMfxWbKzCm0skiDhPVScjvmDR4ti46Rn fDZmTRTsEXtz5LDA== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id C43A72C141; Wed, 24 May 2023 16:03:32 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id B47936649; Wed, 24 May 2023 16:03:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id B2D9763B1; Wed, 24 May 2023 16:03:32 +0000 (UTC) Date: Wed, 24 May 2023 16:03:32 +0000 (UTC) From: Michael Matz To: "Richard Earnshaw (lists)" cc: binutils@sourceware.org Subject: Re: [PATCH] PR30437 aarch64: make RELA relocs idempotent In-Reply-To: <1ba7b2c7-b489-79af-3f2a-56450c86d955@arm.com> Message-ID: References: <1ba7b2c7-b489-79af-3f2a-56450c86d955@arm.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: Hello, On Wed, 24 May 2023, Richard Earnshaw (lists) wrote: > > Tested for aarch64-elf and aarch64-linux (and the other ~150 targets, > > though those can't be affected). Also tested natively on > > aarch64-suse-linux-gnu. Okay for master? > > > > Isn't this what partial_inplace is supposed to describe? Since that's > false, I'd expect any value stored in the section contents to be > ignored. One might think so, yes. But in practice that doesn't seem to be the case (anymore?). I can't quite wrap my head around the logic in reloc.c and interaction between partial_inplace and src_mask. The documentation says that partial_inplace _and_ src_mask should be zero for RELA targets (or rather, that other values are suspicious), and obviously having the former, but not the latter does make a difference. (FWIW, x86_64 recently was fixed as well to have zero src_mask, and most other RELA targets also have it zero) It's possible that partial_inplace only affects partial links (ld -r), at least the docu for that field specifically talks about only that, whereas here (the go bug) we have the problem of a final link where the section contents are non-zero. I don't know if partial_inplace should or should not also affect final links, and if it's a bug that src_mask matters even with !partial_replace. But one of the two needs to yield: either the logic regarding partial_inplace in reloc.c (so that src_mask isn't relevant anymore), or src_mask needs to be zero. The advantage of the latter change is that it's aarch64-specific, whereas a change to partial_inplace handling affects everything and needs more bravery than I have. Either way, even _if_ partial_inplace would be made so that src_mask doesn't matter anymore, then the change to zero src_mask would then still be at least harmless. (skimming some more uses of src_mask relative to uses of partial_inplace in the aarch64 target also shows some more possibly dubious consideration of original section contents in _bfd_aarch64_elf_put_addend. It always looks at the original content and uses src_mask as selector of being for insns or data, but then goes on to mask the read contents only against dst_mask, and not against src_mask. I don't quite know what to make of that) Ciao, Michael.