glibc 2.36 - Slushy freeze (3 weeks to release)

[caiyinyu]

在 2022/7/12 下午7:01, Adhemerval Zanella Netto 写道:
>
>
> On 12/07/22 07:21, Adhemerval Zanella Netto wrote:
>>
>>
>> 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.
>
> It seems the issues I am having is indeed the extra R_LARCH_NONE
> being generated by binutils 2.38 which prevents loader bootstrap.
> This makes current port pretty unusable, so we will need to either?
>
>  * 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.


I can add R_LARCH_NONE handling in boostraping, but there is another 
problem:

binutils 2.38 generates R_LARCH_IRELATIVEs in .rela.plt and now glibc 
loongarch ld.so

has no R_LARCH_IRELATIVEs handling in elf_machine_lazy_rel, this will 
cause ifunc tests to

fail.

I did not find the way to disable ifunc tests by adding configure 
options (if glibc

community can accept loongarch port being tested without ifunc tests), 
so we have to wait

until related patches are merged into binutils community.

Or maybe we can add the following patch back now, and remove it when 
binutils fix

R_LARCH_IRELATIVE's problems.

Any ideas??

Thanks.


 >>>>>>>

diff --git a/sysdeps/loongarch/dl-machine.h b/sysdeps/loongarch/dl-machine.h
index 31111a7372..a615e6774a 100644
--- a/sysdeps/loongarch/dl-machine.h
+++ b/sysdeps/loongarch/dl-machine.h
@@ -258,13 +258,6 @@ elf_machine_lazy_rel (struct link_map *map, struct 
r_scope_elem *scope[],
        else
         *reloc_addr = map->l_mach.plt;
      }
-  else if (__glibc_unlikely (r_type == R_LARCH_IRELATIVE))
-    {
-      ElfW (Addr) *value = (void *) (l_addr + reloc->r_addend);
-      if (__glibc_likely (!skip_ifunc))
-       value = (ElfW (Addr) *) ((ElfW (Addr) (*) (void)) value) ();
-      *reloc_addr = (ElfW (Addr)) value;
-    }
    else
      _dl_reloc_bad_type (map, r_type, 1);
  }
<<<<<<<<