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.