* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
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 ` Andrew Waterman
2 siblings, 0 replies; 21+ messages in thread
From: Jan Beulich @ 2022-07-12 6:19 UTC (permalink / raw)
To: Fangrui Song
Cc: libc-alpha, caiyinyu, liuzhensong, Xi Ruoyao, Wang Xuerui,
binutils, Alan Modra
On 12.07.2022 06:24, Fangrui Song via Binutils wrote:
> On Mon, Jul 11, 2022 at 7:32 PM Alan Modra <amodra@gmail.com> wrote:
>>
>> 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..
>
> If a linker port has a high confidence level, removing dynamic
> R_*_NONE support from the loader shall be the right thing.
How could that be? A dynamic loader ought to support binaries from
all kinds of sources (as long as they're complying to the spec).
What confidence level a particular linker port has shouldn't really
matter imo.
Jan
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
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 9:24 ` Xi Ruoyao
2022-07-12 7:33 ` Andrew Waterman
2 siblings, 2 replies; 21+ messages in thread
From: WANG Xuerui @ 2022-07-12 6:42 UTC (permalink / raw)
To: Fangrui Song, Alan Modra
Cc: Xi Ruoyao, Adhemerval Zanella Netto, Carlos O'Donell,
libc-alpha, binutils, caiyinyu, liuzhensong
On 2022/7/12 12:24, Fangrui Song wrote:
> On Mon, Jul 11, 2022 at 7:32 PM Alan Modra <amodra@gmail.com> wrote:
>> 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..
> If a linker port has a high confidence level, removing dynamic
> R_*_NONE support from the loader shall be the right thing.
> I can understand that there may not be the case in GNU ld as I've seen
> such bugs in riscv (e.g.
> https://sourceware.org/bugzilla/show_bug.cgi?id=24673), too (I think
> gold, lld, and mold make it difficult to make such bugs).
> But I did wish that a fresh port of a new arch in binutils had fixed
> all such bugs. I realized it might be the case for LoongArch, so
> keeping R_LARCH_NONE support in glibc ld.so may be fine.
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).
All is not lost, though, as the LoongArch "new world" (the fully
community-driven openly developed ABI we're currently all working on, as
opposed to the stopgap MIPS-esque ABI Loongson initially shipped in
commercial products) is nowhere near popular, at least in the 1~1.5
years to come; and we as distribution packages already educate the
current "seed" users of new-world LoongArch to expect to update or
re-install as often as possible to stay on the bleeding edge. So IMO
fixing the linker and sunsetting R_LARCH_NONE support in glibc loader
could be feasible after all, just it won't be a quick process.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
2022-07-12 6:42 ` WANG Xuerui
@ 2022-07-12 7:33 ` Florian Weimer
2022-07-12 8:49 ` Xi Ruoyao
2022-07-12 9:24 ` Xi Ruoyao
1 sibling, 1 reply; 21+ messages in thread
From: Florian Weimer @ 2022-07-12 7:33 UTC (permalink / raw)
To: WANG Xuerui
Cc: Fangrui Song, Alan Modra, libc-alpha, caiyinyu, liuzhensong, binutils
* WANG Xuerui:
> All is not lost, though, as the LoongArch "new world" (the fully
> community-driven openly developed ABI we're currently all working on,
> as opposed to the stopgap MIPS-esque ABI Loongson initially shipped in
> commercial products) is nowhere near popular, at least in the 1~1.5
> years to come; and we as distribution packages already educate the
> current "seed" users of new-world LoongArch to expect to update or
> re-install as often as possible to stay on the bleeding edge. So IMO
> fixing the linker and sunsetting R_LARCH_NONE support in glibc loader
> could be feasible after all, just it won't be a quick process.
Does it really make sense to add a glibc port now if we are going to
switch to a different ABI two or three releases from now? I don't think
so.
Thanks,
Florian
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
2022-07-12 7:33 ` Florian Weimer
@ 2022-07-12 8:49 ` Xi Ruoyao
2022-07-12 8:58 ` Florian Weimer
0 siblings, 1 reply; 21+ messages in thread
From: Xi Ruoyao @ 2022-07-12 8:49 UTC (permalink / raw)
To: Florian Weimer, WANG Xuerui
Cc: libc-alpha, caiyinyu, Alan Modra, liuzhensong, binutils
On Tue, 2022-07-12 at 09:33 +0200, Florian Weimer via Libc-alpha wrote:
> Does it really make sense to add a glibc port now if we are going to
> switch to a different ABI two or three releases from now? I don't
> think
> so.
The Glibc patches under review (and the upstreamed kernel/gcc/binutils
code) are already using the new ABI.
The "old" ABI was only used by commercial distros for customers who want
to use LoongArch platforms before all the open source components are
reviewed and upstreamed properly. Old ABI will never be a part of
upstream code.
Once glibc is upstreamed we will consider the ABI stabilized, and start
to encourage people to use upstreamed ABI. (Obviously we can't do it
now: we can't just tell people to "rebuild everything per month".)
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
2022-07-12 8:49 ` Xi Ruoyao
@ 2022-07-12 8:58 ` Florian Weimer
0 siblings, 0 replies; 21+ messages in thread
From: Florian Weimer @ 2022-07-12 8:58 UTC (permalink / raw)
To: Xi Ruoyao via Libc-alpha
Cc: WANG Xuerui, Xi Ruoyao, binutils, Alan Modra, liuzhensong, caiyinyu
* Xi Ruoyao via Libc-alpha:
> On Tue, 2022-07-12 at 09:33 +0200, Florian Weimer via Libc-alpha wrote:
>
>> Does it really make sense to add a glibc port now if we are going to
>> switch to a different ABI two or three releases from now? I don't
>> think
>> so.
>
> The Glibc patches under review (and the upstreamed kernel/gcc/binutils
> code) are already using the new ABI.
>
> The "old" ABI was only used by commercial distros for customers who want
> to use LoongArch platforms before all the open source components are
> reviewed and upstreamed properly. Old ABI will never be a part of
> upstream code.
>
> Once glibc is upstreamed we will consider the ABI stabilized, and start
> to encourage people to use upstreamed ABI. (Obviously we can't do it
> now: we can't just tell people to "rebuild everything per month".)
Okay, that clarifies that aspect, and addresses my concerns. Thanks.
Florian
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
2022-07-12 6:42 ` WANG Xuerui
2022-07-12 7:33 ` Florian Weimer
@ 2022-07-12 9:24 ` Xi Ruoyao
2022-07-12 10:21 ` Adhemerval Zanella Netto
1 sibling, 1 reply; 21+ messages in thread
From: Xi Ruoyao @ 2022-07-12 9:24 UTC (permalink / raw)
To: WANG Xuerui, Fangrui Song, Alan Modra
Cc: Adhemerval Zanella Netto, Carlos O'Donell, libc-alpha,
binutils, caiyinyu, liuzhensong
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
2022-07-12 9:24 ` Xi Ruoyao
@ 2022-07-12 10:21 ` Adhemerval Zanella Netto
2022-07-12 11:01 ` Adhemerval Zanella Netto
0 siblings, 1 reply; 21+ messages in thread
From: Adhemerval Zanella Netto @ 2022-07-12 10:21 UTC (permalink / raw)
To: Xi Ruoyao, WANG Xuerui, Fangrui Song, Alan Modra
Cc: Carlos O'Donell, libc-alpha, binutils, caiyinyu, liuzhensong
On 12/07/22 06:24, Xi Ruoyao wrote:
> 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.
So from a reviewer perspective, what should I use to actually build a
working toolchain where I can actually run the loader and libc using
qemu?
I am currently using git branch of gcc 12, binutils 2.38, and qemu
master and I still can't get the loader to work correctly with
qemu user. This is not really a blocker, but it would be good to
have some validation that current port is actually working somehow
and not dependent on further fixes or backports.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
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 12:48 ` caiyinyu
0 siblings, 2 replies; 21+ messages in thread
From: Adhemerval Zanella Netto @ 2022-07-12 11:01 UTC (permalink / raw)
To: Xi Ruoyao, WANG Xuerui, Fangrui Song, Alan Modra
Cc: Carlos O'Donell, libc-alpha, binutils, caiyinyu, liuzhensong
On 12/07/22 07:21, Adhemerval Zanella Netto wrote:
>
>
> On 12/07/22 06:24, Xi Ruoyao wrote:
>> 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.
>
> So from a reviewer perspective, what should I use to actually build a
> working toolchain where I can actually run the loader and libc using
> qemu?
>
> I am currently using git branch of gcc 12, binutils 2.38, and qemu
> master and I still can't get the loader to work correctly with
> qemu user. This is not really a blocker, but it would be good to
> have some validation that current port is actually working somehow
> and not dependent on further fixes or backports.
It seems the issues I am having is indeed the extra R_LARCH_NONE
being generated by binutils 2.38 which prevents loader bootstrap.
This makes current port pretty unusable, so we will need to either?
* Fix the R_LARCH_NONE generation and backport it to 2.38, or bump
the minimum required version to 2.39. This will hold any inclusion
on glibc until binutils is fixed.
* Add R_LARCH_NONE handling in boostraping. This is a simpler solution
and although it might hinder some possible bugs in static linker,
I think for current port status it the best option.
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
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 12:48 ` caiyinyu
1 sibling, 1 reply; 21+ messages in thread
From: Michael Matz @ 2022-07-12 12:15 UTC (permalink / raw)
To: Adhemerval Zanella Netto
Cc: Xi Ruoyao, WANG Xuerui, Fangrui Song, Alan Modra, liuzhensong,
libc-alpha, binutils, caiyinyu
Hey,
On Tue, 12 Jul 2022, Adhemerval Zanella Netto via Binutils wrote:
> * Fix the R_LARCH_NONE generation and backport it to 2.38, or bump
> the minimum required version to 2.39. This will hold any inclusion
> on glibc until binutils is fixed.
>
> * Add R_LARCH_NONE handling in boostraping. This is a simpler solution
> and although it might hinder some possible bugs in static linker,
> I think for current port status it the best option.
Postel's law is always good advise. "Be strict in what you generate, be
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.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
2022-07-12 12:15 ` Michael Matz
@ 2022-07-12 13:17 ` Florian Weimer
2022-07-12 13:28 ` Michael Matz
0 siblings, 1 reply; 21+ messages in thread
From: Florian Weimer @ 2022-07-12 13:17 UTC (permalink / raw)
To: Michael Matz via Libc-alpha
Cc: Adhemerval Zanella Netto, Michael Matz, Alan Modra, caiyinyu,
liuzhensong, WANG Xuerui, binutils
* Michael Matz via Libc-alpha:
> Hey,
>
> On Tue, 12 Jul 2022, Adhemerval Zanella Netto via Binutils wrote:
>
>> * Fix the R_LARCH_NONE generation and backport it to 2.38, or bump
>> the minimum required version to 2.39. This will hold any inclusion
>> on glibc until binutils is fixed.
>>
>> * Add R_LARCH_NONE handling in boostraping. This is a simpler solution
>> and although it might hinder some possible bugs in static linker,
>> I think for current port status it the best option.
>
> Postel's law is always good advise. "Be strict in what you generate, be
> 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. And missing run-time relocations
can be quite challenging to diagnose. In a sense, the loader has to
reject R_*_NONE relocations to avoid generating bogus relocated data.
Thanks,
Florian
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
2022-07-12 13:17 ` Florian Weimer
@ 2022-07-12 13:28 ` Michael Matz
2022-07-15 22:34 ` Hans-Peter Nilsson
0 siblings, 1 reply; 21+ messages in thread
From: Michael Matz @ 2022-07-12 13:28 UTC (permalink / raw)
To: Florian Weimer
Cc: Michael Matz via Libc-alpha, Adhemerval Zanella Netto,
Alan Modra, caiyinyu, liuzhensong, WANG Xuerui, binutils
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
2022-07-12 13:28 ` Michael Matz
@ 2022-07-15 22:34 ` Hans-Peter Nilsson
0 siblings, 0 replies; 21+ messages in thread
From: Hans-Peter Nilsson @ 2022-07-15 22:34 UTC (permalink / raw)
To: Michael Matz
Cc: Florian Weimer, Michael Matz via Libc-alpha, caiyinyu,
liuzhensong, binutils
On Tue, 12 Jul 2022, Michael Matz via Binutils wrote:
> 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.
(From the department of opinions nobody asked for:)
This is IMHO the most correct assessment. And, beware of adding
new potentially relocation-removing linker optimizations after
section layout. I'd add something about fighting windmills, but
the "strive for purity" fits nicely. :)
brgds, H-P
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
2022-07-12 11:01 ` Adhemerval Zanella Netto
2022-07-12 12:15 ` Michael Matz
@ 2022-07-12 12:48 ` caiyinyu
2022-07-12 13:00 ` Xi Ruoyao
1 sibling, 1 reply; 21+ messages in thread
From: caiyinyu @ 2022-07-12 12:48 UTC (permalink / raw)
To: Adhemerval Zanella Netto, Xi Ruoyao, WANG Xuerui, Fangrui Song,
Alan Modra
Cc: Carlos O'Donell, libc-alpha, binutils, liuzhensong
在 2022/7/12 下午7:01, Adhemerval Zanella Netto 写道:
>
>
> On 12/07/22 07:21, Adhemerval Zanella Netto wrote:
>>
>>
>> On 12/07/22 06:24, Xi Ruoyao wrote:
>>> 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.
>>
>> So from a reviewer perspective, what should I use to actually build a
>> working toolchain where I can actually run the loader and libc using
>> qemu?
>>
>> I am currently using git branch of gcc 12, binutils 2.38, and qemu
>> master and I still can't get the loader to work correctly with
>> qemu user. This is not really a blocker, but it would be good to
>> have some validation that current port is actually working somehow
>> and not dependent on further fixes or backports.
>
> It seems the issues I am having is indeed the extra R_LARCH_NONE
> being generated by binutils 2.38 which prevents loader bootstrap.
> This makes current port pretty unusable, so we will need to either?
>
> * Fix the R_LARCH_NONE generation and backport it to 2.38, or bump
> the minimum required version to 2.39. This will hold any inclusion
> on glibc until binutils is fixed.
>
> * Add R_LARCH_NONE handling in boostraping. This is a simpler solution
> and although it might hinder some possible bugs in static linker,
> I think for current port status it the best option.
I can add R_LARCH_NONE handling in boostraping, but there is another
problem:
binutils 2.38 generates R_LARCH_IRELATIVEs in .rela.plt and now glibc
loongarch ld.so
has no R_LARCH_IRELATIVEs handling in elf_machine_lazy_rel, this will
cause ifunc tests to
fail.
I did not find the way to disable ifunc tests by adding configure
options (if glibc
community can accept loongarch port being tested without ifunc tests),
so we have to wait
until related patches are merged into binutils community.
Or maybe we can add the following patch back now, and remove it when
binutils fix
R_LARCH_IRELATIVE's problems.
Any ideas??
Thanks.
>>>>>>>
diff --git a/sysdeps/loongarch/dl-machine.h b/sysdeps/loongarch/dl-machine.h
index 31111a7372..a615e6774a 100644
--- a/sysdeps/loongarch/dl-machine.h
+++ b/sysdeps/loongarch/dl-machine.h
@@ -258,13 +258,6 @@ elf_machine_lazy_rel (struct link_map *map, struct
r_scope_elem *scope[],
else
*reloc_addr = map->l_mach.plt;
}
- else if (__glibc_unlikely (r_type == R_LARCH_IRELATIVE))
- {
- ElfW (Addr) *value = (void *) (l_addr + reloc->r_addend);
- if (__glibc_likely (!skip_ifunc))
- value = (ElfW (Addr) *) ((ElfW (Addr) (*) (void)) value) ();
- *reloc_addr = (ElfW (Addr)) value;
- }
else
_dl_reloc_bad_type (map, r_type, 1);
}
<<<<<<<<
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
2022-07-12 12:48 ` caiyinyu
@ 2022-07-12 13:00 ` Xi Ruoyao
0 siblings, 0 replies; 21+ messages in thread
From: Xi Ruoyao @ 2022-07-12 13:00 UTC (permalink / raw)
To: caiyinyu, Adhemerval Zanella Netto, WANG Xuerui, Fangrui Song,
Alan Modra
Cc: Carlos O'Donell, libc-alpha, binutils, liuzhensong
On Tue, 2022-07-12 at 20:48 +0800, caiyinyu wrote:
> I can add R_LARCH_NONE handling in boostraping, but there is another
> problem:
>
> binutils 2.38 generates R_LARCH_IRELATIVEs in .rela.plt and now glibc
> loongarch ld.so has no R_LARCH_IRELATIVEs handling in elf_machine_lazy_rel, this will
> cause ifunc tests to fail.
>
> I did not find the way to disable ifunc tests by adding configure
> options (if glibc community can accept loongarch port being tested without ifunc tests),
> so we have to wait until related patches are merged into binutils community.
"libc_cv_ld_gnu_indirect_function=no" (just append it into configure
command line, not "--libc_cv_...", nor "--disable-...") will do the job.
I'm not sure how much effort is needed to fix R_LARCH_IRELATIVE issue.
If it's trivial I still suggests to get it reviewed and accepted by
binutils ASAP. But if it's very tricky (like R_LARCH_NONE) we can
disable ifunc support for now by setting
libc_cv_ld_gnu_indirect_function=no in machine-specific configure.ac
(use commit 600c13b "hurd: disable ifunc for now" as a reference).
> Or maybe we can add the following patch back now, and remove it when
> binutils fix R_LARCH_IRELATIVE's problems.
I don't think it's an option: if a shared object is loaded fine with
Glibc-2.36 but rejected by 2.37, we call it a "regression" or "bug".
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: glibc 2.36 - Slushy freeze (3 weeks to release)
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 ` Andrew Waterman
2 siblings, 0 replies; 21+ messages in thread
From: Andrew Waterman @ 2022-07-12 7:33 UTC (permalink / raw)
To: Fangrui Song
Cc: Alan Modra, libc-alpha, caiyinyu, liuzhensong, Xi Ruoyao,
Wang Xuerui, Binutils
On Mon, Jul 11, 2022 at 9:25 PM Fangrui Song via Binutils
<binutils@sourceware.org> wrote:
>
> On Mon, Jul 11, 2022 at 7:32 PM Alan Modra <amodra@gmail.com> wrote:
> >
> > 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..
This thread attracted my attention because of the stray mention of
RISC-V. I'd just like to comment that this appears to me to be an
aesthetically motivated change. It's hard to support breaking
existing code on this basis, even if the code was theoretically
ABI-incompliant to begin with. Why can't we just leave well enough
alone?
>
> If a linker port has a high confidence level, removing dynamic
> R_*_NONE support from the loader shall be the right thing.
> I can understand that there may not be the case in GNU ld as I've seen
> such bugs in riscv (e.g.
> https://sourceware.org/bugzilla/show_bug.cgi?id=24673), too (I think
> gold, lld, and mold make it difficult to make such bugs).
> But I did wish that a fresh port of a new arch in binutils had fixed
> all such bugs. I realized it might be the case for LoongArch, so
> keeping R_LARCH_NONE support in glibc ld.so may be fine.
^ permalink raw reply [flat|nested] 21+ messages in thread