Re: glibc 2.36 - Slushy freeze (3 weeks to release)

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Xi Ruoyao]

+binutils because we'll have to discuss binutils-related issues.

On Mon, 2022-07-11 at 11:20 -0400, Carlos O'Donell via Libc-alpha wrote:

> Desirable:
> 
> * GLIBC LoongArch PATCHES
> 
> The LoongArch patches are currently under review, but there looks to be
> some unresolved binutils issues. Just for clarity we expect a glibc port
> to have committed patches for the linux kernel, gcc, and binutils before
> inclusion in glibc.

GCC is mostly fine.  There are some "outstanding" bugs in 12.1 but AFAIK
they don't cause issues building glibc.  You can use releases/gcc-12
branch if you have any doubt.

Kernel userspace API is fine in 5.19-rc.  There are issues about boot
protocol and some drivers but these issues are completely unrelated to
glibc.

For binutils, ld is generating strange R_LARCH_NONE relocations (caused
by an over-allocate of .rel.* sections and the usage of 0 as padding),
and ld is generating R_LARCH_IRELATIVE for .rel.plt section (Fangrui
says .rel.plt should not contain R_LARCH_IRELATIVE).

Loongson engineers seems preparing a large patch series containing
*both* the bug fix removing buggy R_LARCH_NONE and R_LARCH_IRELATIVE
relocations, *and* the implementation of many new relocation types
(superseding the current stack-based relocs which are disliked by many
people, including me).

Unfortunately, binutils 2.39 release branch is already created and I
don't think such a large change set can be reviewed and landed into
binutils soon.  So I'll repeat my suggestion again: it's better to
separate the bug fix and the new feature into two patch series, and get
the bug fix landed and backported for binutils-2.39 branch ASAP.  The
new relocs (and/or other new features) can be reviewed later for
binutils 2.40, after 2.39 release.

I don't like the stack-based relocs, maybe even more than you guys - I
remember I'd shout loudly with "colorful metaphors" when I had to use
these relocs in LLVM.  However another binutils release "supporting"
LoongArch but completely unusable in practice will be worse.  (Remind:
2.38 is already such a release.)

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Adhemerval Zanella Netto]

On 11/07/22 13:06, Xi Ruoyao via Binutils wrote:
> +binutils because we'll have to discuss binutils-related issues.
> 
> On Mon, 2022-07-11 at 11:20 -0400, Carlos O'Donell via Libc-alpha wrote:
> 
>> Desirable:
>>
>> * GLIBC LoongArch PATCHES
>>
>> The LoongArch patches are currently under review, but there looks to be
>> some unresolved binutils issues. Just for clarity we expect a glibc port
>> to have committed patches for the linux kernel, gcc, and binutils before
>> inclusion in glibc.
> 
> GCC is mostly fine.  There are some "outstanding" bugs in 12.1 but AFAIK
> they don't cause issues building glibc.  You can use releases/gcc-12
> branch if you have any doubt.
> 
> Kernel userspace API is fine in 5.19-rc.  There are issues about boot
> protocol and some drivers but these issues are completely unrelated to
> glibc.
> 
> For binutils, ld is generating strange R_LARCH_NONE relocations (caused
> by an over-allocate of .rel.* sections and the usage of 0 as padding),
> and ld is generating R_LARCH_IRELATIVE for .rel.plt section (Fangrui
> says .rel.plt should not contain R_LARCH_IRELATIVE).
> 
> Loongson engineers seems preparing a large patch series containing
> *both* the bug fix removing buggy R_LARCH_NONE and R_LARCH_IRELATIVE
> relocations, *and* the implementation of many new relocation types
> (superseding the current stack-based relocs which are disliked by many
> people, including me).
> 
> Unfortunately, binutils 2.39 release branch is already created and I
> don't think such a large change set can be reviewed and landed into
> binutils soon.  So I'll repeat my suggestion again: it's better to
> separate the bug fix and the new feature into two patch series, and get
> the bug fix landed and backported for binutils-2.39 branch ASAP.  The
> new relocs (and/or other new features) can be reviewed later for
> binutils 2.40, after 2.39 release.
> 
> I don't like the stack-based relocs, maybe even more than you guys - I
> remember I'd shout loudly with "colorful metaphors" when I had to use
> these relocs in LLVM.  However another binutils release "supporting"
> LoongArch but completely unusable in practice will be worse.  (Remind:
> 2.38 is already such a release.)

So do we need a binutils 2.39 to have a workable glibc build or is the
2.38 suffice? 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.

For R_LARCH_IRELATIVE I think we can just disable ifunc support for
now and re-enable on 2.37 once it is properly fixed on binutils (maybe
also bumping minimum required binutils).

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Xi Ruoyao]

On Mon, 2022-07-11 at 16:10 -0300, Adhemerval Zanella Netto wrote:
> 
> 
> On 11/07/22 13:06, Xi Ruoyao via Binutils wrote:
> > +binutils because we'll have to discuss binutils-related issues.
> > 
> > On Mon, 2022-07-11 at 11:20 -0400, Carlos O'Donell via Libc-alpha
> > wrote:
> > 
> > > Desirable:
> > > 
> > > * GLIBC LoongArch PATCHES
> > > 
> > > The LoongArch patches are currently under review, but there looks
> > > to be
> > > some unresolved binutils issues. Just for clarity we expect a
> > > glibc port
> > > to have committed patches for the linux kernel, gcc, and binutils
> > > before
> > > inclusion in glibc.
> > 
> > GCC is mostly fine.  There are some "outstanding" bugs in 12.1 but
> > AFAIK
> > they don't cause issues building glibc.  You can use releases/gcc-12
> > branch if you have any doubt.
> > 
> > Kernel userspace API is fine in 5.19-rc.  There are issues about
> > boot
> > protocol and some drivers but these issues are completely unrelated
> > to
> > glibc.
> > 
> > For binutils, ld is generating strange R_LARCH_NONE relocations
> > (caused
> > by an over-allocate of .rel.* sections and the usage of 0 as
> > padding),
> > and ld is generating R_LARCH_IRELATIVE for .rel.plt section (Fangrui
> > says .rel.plt should not contain R_LARCH_IRELATIVE).
> > 
> > Loongson engineers seems preparing a large patch series containing
> > *both* the bug fix removing buggy R_LARCH_NONE and R_LARCH_IRELATIVE
> > relocations, *and* the implementation of many new relocation types
> > (superseding the current stack-based relocs which are disliked by
> > many
> > people, including me).
> > 
> > Unfortunately, binutils 2.39 release branch is already created and I
> > don't think such a large change set can be reviewed and landed into
> > binutils soon.  So I'll repeat my suggestion again: it's better to
> > separate the bug fix and the new feature into two patch series, and
> > get
> > the bug fix landed and backported for binutils-2.39 branch ASAP. 
> > The
> > new relocs (and/or other new features) can be reviewed later for
> > binutils 2.40, after 2.39 release.
> > 
> > I don't like the stack-based relocs, maybe even more than you guys -
> > I
> > remember I'd shout loudly with "colorful metaphors" when I had to
> > use
> > these relocs in LLVM.  However another binutils release "supporting"
> > LoongArch but completely unusable in practice will be worse. 
> > (Remind:
> > 2.38 is already such a release.)
> 
> So do we need a binutils 2.39 to have a workable glibc build or is the
> 2.38 suffice?

We need a 2.39, or backport one change [1] to 2.38.

[1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3b14682a

> 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.

Fangrui suggested [2] we should assume R_LARCH_NONE does not exist to
simplify the code and catch ld bugs earlier.  So the code ignoring
R_LARCH_NONE is moved into #ifndef RTLD_BOOTSTRAP in the latest patch
[3].  My experiment shows it causes a segfault starting ld.so.  ld.so
bootstrapping really hits R_LARCH_NONE, and the execution path falls
into _dl_reloc_bad_type.  But using _dl_reloc_bad_type before bootstrap
complete just leads to a segfault (as the error reporting functions like
_dl_signal_error are not relocated correctly yet).

[2]: https://sourceware.org/pipermail/libc-alpha/2022-June/139424.html
[3]: https://sourceware.org/pipermail/libc-alpha/2022-July/140451.html

I agree to just ignore R_LARCH_NONE at all, because "we are not binutils
test suite".

> For R_LARCH_IRELATIVE I think we can just disable ifunc support for
> now and re-enable on 2.37 once it is properly fixed on binutils (maybe
> also bumping minimum required binutils).

I agree with this approach.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Xi Ruoyao]

On Tue, 2022-07-12 at 08:48 +0800, Xi Ruoyao via Libc-alpha wrote:

> > So do we need a binutils 2.39 to have a workable glibc build or is the
> > 2.38 suffice?
> 
> We need a 2.39, or backport one change [1] to 2.38.
> 
> [1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3b14682a

P. S. this change is not only needed to build glibc, but also needed to
build anything with GCC.  That's why I said "completely unusable". 
Maybe "completely" is too strong: 2.38 is functional with this change
backported.

And yes, it's already backported into binutils-2.38 branch [2].  But we
didn't get a new 2.38.1 release containing it :(.

[2]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d54081c6

(To be fair: a plain binutils-2.38 release also does not work fine for
x86 and we had to backport changes [3][4] too.)

[3]: https://wiki.linuxfromscratch.org/lfs/ticket/5011
[4]: https://wiki.linuxfromscratch.org/lfs/ticket/5012
-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Alan Modra]

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

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Fangrui Song]

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.

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Jan Beulich]

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

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[WANG Xuerui]

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.

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Florian Weimer]

* 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

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Andrew Waterman]

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.

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Xi Ruoyao]

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

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Florian Weimer]

* 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

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Xi Ruoyao]

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

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Adhemerval Zanella Netto]

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.

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[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.

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Michael Matz]

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.

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[caiyinyu]

在 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);
  }
<<<<<<<<

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Xi Ruoyao]

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

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Florian Weimer]

* 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

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Michael Matz]

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.

Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Hans-Peter Nilsson]

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