From: Michael Matz <matz@suse.de>
To: Florian Weimer <fweimer@redhat.com>
Cc: Michael Matz via Libc-alpha <libc-alpha@sourceware.org>,
Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
Alan Modra <amodra@gmail.com>, caiyinyu <caiyinyu@loongson.cn>,
liuzhensong <liuzhensong@loongson.cn>,
WANG Xuerui <i.swmail@xen0n.name>,
binutils@sourceware.org
Subject: Re: glibc 2.36 - Slushy freeze (3 weeks to release)
Date: Tue, 12 Jul 2022 13:28:30 +0000 (UTC) [thread overview]
Message-ID: <alpine.LSU.2.20.2207121318150.24606@wotan.suse.de> (raw)
In-Reply-To: <87fsj6sc6p.fsf@oldenburg.str.redhat.com>
Hello,
On Tue, 12 Jul 2022, Florian Weimer wrote:
> > lenient in what you accept", even more so for something so basic as a
> > program loader. It seems ill-advised to use ld.so to force something
> > onto users that can only be called a strive for purity.
>
> The problem here is that R_*_NONE has historically been used in binutils
> to indicate, “I did not recognize the relocation in the input file”,
> while still generating an output file.
The usual reason for _NONE are overallocated .rel output sections,
where then further optimizations (after section sizes and hence base
addresses are fixed) got rid of some of those relocations. (All these
cases can be considered missed optimizations, but those happen easily)
Unrecognizable input relocations are usually errored out on (and should
be!) and don't lead to random _NONE output relocs, for exactly the reason
you cited.
Ciao,
Michael.
next prev parent reply other threads:[~2022-07-12 13:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fef8c3c7-fd30-d8b5-e539-f0f21d562c51@redhat.com>
2022-07-11 16:06 ` Xi Ruoyao
2022-07-11 19:10 ` Adhemerval Zanella Netto
2022-07-12 0:48 ` Xi Ruoyao
2022-07-12 1:02 ` Xi Ruoyao
2022-07-12 2:32 ` Alan Modra
2022-07-12 4:24 ` Fangrui Song
2022-07-12 6:19 ` Jan Beulich
2022-07-12 6:42 ` WANG Xuerui
2022-07-12 7:33 ` Florian Weimer
2022-07-12 8:49 ` Xi Ruoyao
2022-07-12 8:58 ` Florian Weimer
2022-07-12 9:24 ` Xi Ruoyao
2022-07-12 10:21 ` Adhemerval Zanella Netto
2022-07-12 11:01 ` Adhemerval Zanella Netto
2022-07-12 12:15 ` Michael Matz
2022-07-12 13:17 ` Florian Weimer
2022-07-12 13:28 ` Michael Matz [this message]
2022-07-15 22:34 ` Hans-Peter Nilsson
2022-07-12 12:48 ` caiyinyu
2022-07-12 13:00 ` Xi Ruoyao
2022-07-12 7:33 ` Andrew Waterman
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.2207121318150.24606@wotan.suse.de \
--to=matz@suse.de \
--cc=adhemerval.zanella@linaro.org \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=caiyinyu@loongson.cn \
--cc=fweimer@redhat.com \
--cc=i.swmail@xen0n.name \
--cc=libc-alpha@sourceware.org \
--cc=liuzhensong@loongson.cn \
/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).