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.