Re: glibc 2.36 - Slushy freeze (3 weeks to release)

[Xi Ruoyao <xry111@xry111.site>]

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