From: Alan Modra <amodra@gmail.com>
To: Xi Ruoyao <xry111@xry111.site>
Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
Carlos O'Donell <carlos@redhat.com>,
libc-alpha <libc-alpha@sourceware.org>,
binutils@sourceware.org, caiyinyu <caiyinyu@loongson.cn>,
Wang Xuerui <i@xen0n.name>, Fangrui Song <maskray@google.com>,
liuzhensong <liuzhensong@loongson.cn>
Subject: Re: glibc 2.36 - Slushy freeze (3 weeks to release)
Date: Tue, 12 Jul 2022 12:02:05 +0930 [thread overview]
Message-ID: <YszdJQAvZ8D3Gebk@squeak.grove.modra.org> (raw)
In-Reply-To: <d08a21a6a3b6f58bc9b99a0526b2ef53400e55be.camel@xry111.site>
On Tue, Jul 12, 2022 at 08:48:18AM +0800, Xi Ruoyao via Binutils wrote:
> > The R_LARCH_NONE issue should only affect performance,
> > since it should be ignored by loader although I am not sure without
> > understanding better the issue.
R_*_NONE relocs are harmless in an executable or shared library, if
their presence is due to overallocating space for relocations. Of
course, if ld should actually be emitting some other dynamic reloc
type then that is a more serious problem.
> Fangrui suggested [2] we should assume R_LARCH_NONE does not exist to
> simplify the code and catch ld bugs earlier.
Yes that will annoy your user base into reporting bugs. How much do
you want to annoy them? You might like to consider why other major
architectures with mature linkers process and ignore R_*_NONE relocs
in the loader..
--
Alan Modra
Australia Development Lab, IBM
next prev parent reply other threads:[~2022-07-12 2:32 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 [this message]
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
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=YszdJQAvZ8D3Gebk@squeak.grove.modra.org \
--to=amodra@gmail.com \
--cc=adhemerval.zanella@linaro.org \
--cc=binutils@sourceware.org \
--cc=caiyinyu@loongson.cn \
--cc=carlos@redhat.com \
--cc=i@xen0n.name \
--cc=libc-alpha@sourceware.org \
--cc=liuzhensong@loongson.cn \
--cc=maskray@google.com \
--cc=xry111@xry111.site \
/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).