glibc 2.36 - Slushy freeze (3 weeks to release)
Florian Weimer
fweimer@redhat.com
Tue Jul 12 13:17:02 GMT 2022
* 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
More information about the Binutils
mailing list