From: Xi Ruoyao <xry111@xry111.site>
To: WANG Xuerui <i.swmail@xen0n.name>,
Fangrui Song <maskray@google.com>, Alan Modra <amodra@gmail.com>
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>,
liuzhensong <liuzhensong@loongson.cn>
Subject: Re: glibc 2.36 - Slushy freeze (3 weeks to release)
Date: Tue, 12 Jul 2022 17:24:58 +0800 [thread overview]
Message-ID: <ed085e2e544bd50a737e45b94938b0c76ea4854f.camel@xry111.site> (raw)
In-Reply-To: <ada40d73-6b93-da19-a23c-de35ee3315a0@xen0n.name>
On Tue, 2022-07-12 at 14:42 +0800, WANG Xuerui wrote:
> It's generally nice to be able to remove dubious/superfluous/unused
> code, but doing so must not negatively affect users. I'm personally in
> support of removing such code, but as others have pointed out, it's
> unfortunate that the LoongArch port turns out to have "inherited" the
> wart from elsewhere, so the removal should not be done lightly (and
> break users' systems).
I can live with either
(1) Fix Binutils-2.39 ASAP and remove R_LARCH_NONE handling in Glibc.
And document "To build Glibc-2.36 or any code link to Glibc-2.36 for
LoongArch, Binutils >= 2.39 is needed."
(2) Work around R_LARCH_NONE in Glibc rtld code.
The advantage of (1) is we can get rid of "some stupid code" and make
some marginal performance gain. The disadvantage is we are too close to
the deadline (glibc-2.36 and binutils-2.39 due date) and if we fail
we'll wait for another 6 months to upstream Glibc.
But, "just remove R_LARCH_NONE in Glibc rtld and tell everyone to build
Glibc-2.36 (and everything link to it) for LoongArch with
/path/to/not/reviewed/binutils.git/some-fancy-branch" is not acceptable
to me.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
next prev parent reply other threads:[~2022-07-12 9:25 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 [this message]
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=ed085e2e544bd50a737e45b94938b0c76ea4854f.camel@xry111.site \
--to=xry111@xry111.site \
--cc=adhemerval.zanella@linaro.org \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=caiyinyu@loongson.cn \
--cc=carlos@redhat.com \
--cc=i.swmail@xen0n.name \
--cc=libc-alpha@sourceware.org \
--cc=liuzhensong@loongson.cn \
--cc=maskray@google.com \
/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).