glibc 2.36 - Slushy freeze (3 weeks to release)

[Xi Ruoyao]

On Mon, 2022-07-11 at 16:10 -0300, Adhemerval Zanella Netto wrote:
> 
> 
> 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?

We need a 2.39, or backport one change [1] to 2.38.

[1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3b14682a

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

Fangrui suggested [2] we should assume R_LARCH_NONE does not exist to
simplify the code and catch ld bugs earlier.  So the code ignoring
R_LARCH_NONE is moved into #ifndef RTLD_BOOTSTRAP in the latest patch
[3].  My experiment shows it causes a segfault starting ld.so.  ld.so
bootstrapping really hits R_LARCH_NONE, and the execution path falls
into _dl_reloc_bad_type.  But using _dl_reloc_bad_type before bootstrap
complete just leads to a segfault (as the error reporting functions like
_dl_signal_error are not relocated correctly yet).

[2]: https://sourceware.org/pipermail/libc-alpha/2022-June/139424.html
[3]: https://sourceware.org/pipermail/libc-alpha/2022-July/140451.html

I agree to just ignore R_LARCH_NONE at all, because "we are not binutils
test suite".

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

I agree with this approach.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University