From: Michael Matz <matz@suse.de>
To: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH] PR30437 aarch64: make RELA relocs idempotent
Date: Wed, 24 May 2023 16:03:32 +0000 (UTC) [thread overview]
Message-ID: <alpine.LSU.2.20.2305241535170.13548@wotan.suse.de> (raw)
In-Reply-To: <1ba7b2c7-b489-79af-3f2a-56450c86d955@arm.com>
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.
next prev parent reply other threads:[~2023-05-24 16:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 14:04 Michael Matz
2023-05-17 14:35 ` Nick Clifton
2023-05-24 15:26 ` Richard Earnshaw (lists)
2023-05-24 16:03 ` Michael Matz [this message]
2023-05-25 9:35 ` Richard Earnshaw (lists)
2023-05-25 12:29 ` Michael Matz
2023-05-25 13:22 ` Richard Earnshaw (lists)
2023-05-25 14:12 ` Michael Matz
2023-05-25 15:56 ` Richard Earnshaw (lists)
2023-05-25 16:01 ` Michael Matz
2023-05-24 22:54 ` Alan Modra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LSU.2.20.2305241535170.13548@wotan.suse.de \
--to=matz@suse.de \
--cc=Richard.Earnshaw@arm.com \
--cc=binutils@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).