From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id A0EEC3858C50; Tue, 12 Jul 2022 12:48:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A0EEC3858C50 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from [10.20.4.187] (unknown [10.20.4.187]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9Dx79Ofbc1iY10ZAA--.16545S3; Tue, 12 Jul 2022 20:48:31 +0800 (CST) Subject: Re: glibc 2.36 - Slushy freeze (3 weeks to release) To: Adhemerval Zanella Netto , Xi Ruoyao , WANG Xuerui , Fangrui Song , Alan Modra Cc: Carlos O'Donell , libc-alpha , binutils@sourceware.org, liuzhensong References: <7aba5486-ac02-2088-221e-513a6892817a@linaro.org> <612c015a-8d77-d0ee-773a-c51e9cb1d239@linaro.org> <74d08933-d426-c25d-8496-5bd1c76c396b@linaro.org> From: caiyinyu Message-ID: <12b025a3-7d10-a9c6-d9e1-54bd3fdca5fe@loongson.cn> Date: Tue, 12 Jul 2022 20:48:31 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <74d08933-d426-c25d-8496-5bd1c76c396b@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID: AQAAf9Dx79Ofbc1iY10ZAA--.16545S3 X-Coremail-Antispam: 1UD129KBjvJXoWxGw43AFy7Xw48Ww15Zw43KFg_yoWrXFW8pr y8GF1FkrWkCF1xWr1qy345ua40vrW8J3y7XryrJFykAFZ0qry0grWFvwnI9ay7Gw40qr15 Zr10q3Z3u3WkArJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvS14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26F1j6w1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j 6r4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcVAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwCYjI0SjxkI62AI1cAE67vI Y487MxkIecxEwVCm-wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s 026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_ Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20x vEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280 aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43 ZEXa7VUbXdbUUUUUU== X-CM-SenderInfo: 5fdl5xhq1xqz5rrqw2lrqou0/ X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, BODY_8BITS, GIT_PATCH_0, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2022 12:48:39 -0000 在 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);  } <<<<<<<<