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

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 12/07/22 06:24, Xi Ruoyao wrote:
> On Tue, 2022-07-12 at 14:42 +0800, WANG Xuerui wrote:
> 
>> 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).
> 
> I can live with either
> 
> (1) Fix Binutils-2.39 ASAP and remove R_LARCH_NONE handling in Glibc.
> And document "To build Glibc-2.36 or any code link to Glibc-2.36 for
> LoongArch, Binutils >= 2.39 is needed."
> (2) Work around R_LARCH_NONE in Glibc rtld code.
> 
> The advantage of (1) is we can get rid of "some stupid code" and make
> some marginal performance gain.  The disadvantage is we are too close to
> the deadline (glibc-2.36 and binutils-2.39 due date) and if we fail
> we'll wait for another 6 months to upstream Glibc.
> 
> But, "just remove R_LARCH_NONE in Glibc rtld and tell everyone to build
> Glibc-2.36 (and everything link to it) for LoongArch with
> /path/to/not/reviewed/binutils.git/some-fancy-branch" is not acceptable
> to me.

So from a reviewer perspective, what should I use to actually build a
working toolchain where I can actually run the loader and libc using
qemu?

I am currently using git branch of gcc 12, binutils 2.38, and qemu
master and I still can't get the loader to work correctly with
qemu user.  This is not really a blocker, but it would be good to
have some validation that current port is actually working somehow
and not dependent on further fixes or backports.