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.