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