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 5541B3858439 for ; Tue, 19 Jul 2022 07:26:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5541B3858439 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.151] (unknown [10.20.4.151]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9AxKeCmXNZiQQYoAA--.12372S3; Tue, 19 Jul 2022 15:26:32 +0800 (CST) Subject: Re: [PATCH 4/5 v1] LoongArch: Move ifunc info to rela.dyn from rela.plt. To: Xi Ruoyao , binutils@sourceware.org Cc: xuchenghua@loongson.cn, mengqinggang@loongson.cn, WANG Xuerui References: <20220718084316.390672-1-liuzhensong@loongson.cn> <20220718084316.390672-4-liuzhensong@loongson.cn> <3e53c1fcc7b4599340f341988e07b86d7a911ab8.camel@xry111.site> From: liuzhensong Message-ID: Date: Tue, 19 Jul 2022 15:26:30 +0800 User-Agent: Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <3e53c1fcc7b4599340f341988e07b86d7a911ab8.camel@xry111.site> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID: AQAAf9AxKeCmXNZiQQYoAA--.12372S3 X-Coremail-Antispam: 1UD129KBjvJXoW7AF4fCFW8tFWfuFyfZw1fZwb_yoW8AFyrpr y3Jr9IkFW3tFyxtayqgw4xWr15trZ3uFy5Jr90q34vyrs8G3Z5Xr1FqrWjga47Aw15GrWj vFW5Wrs0kF1FyFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvm14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I8E87Iv6xkF7I0E14v26r xl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj 6xIIjxv20xvE14v26r1q6rW5McIj6I8E87Iv67AKxVW8JVWxJwAm72CE4IkC6x0Yz7v_Jr 0_Gr1lF7xvr2IY64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7Mxk0xIA0c2IEe2xFo4CE bIxvr21lc2xSY4AK6svPMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI 8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AK xVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI 8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2 z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnU UI43ZEXa7VUjTKZJUUUUU== X-CM-SenderInfo: holx6xphqv003j6o00pqjv00gofq/ X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP 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, 19 Jul 2022 07:26:36 -0000 在 2022/7/19 上午12:27, Xi Ruoyao 写道: > On Mon, 2022-07-18 at 16:43 +0800, liuzhensong wrote: >>   Delete R_LARCH_IRELATIVE from dynamic loader (glibc ld.so) when >>   loading lazy function (rela.plt section). >> >>   In dynamic programes, move ifunc dynamic relocate info to section >>   srelgot from srelplt. > The main point of this change is allowing us to enable ifunc support for > Glibc, right? > > But have you tested building Glibc using a ld with this series applied? > It does not work well for me: > > FAIL: elf/ifuncmain1 > FAIL: elf/ifuncmain1pic > FAIL: elf/ifuncmain1pie > FAIL: elf/ifuncmain1staticpic > FAIL: elf/ifuncmain1staticpie > FAIL: elf/ifuncmain1vis > FAIL: elf/ifuncmain1vispic > FAIL: elf/ifuncmain1vispie > FAIL: elf/ifuncmain3 > FAIL: elf/ifuncmain4 > FAIL: elf/ifuncmain5staticpic > FAIL: elf/ifuncmain7 > FAIL: elf/ifuncmain7pic > FAIL: elf/ifuncmain7pie > > Note that Binutils test suite is far from complete. For example, the > ifunc handling for LoongArch target in master branch (with or w/o this > patch) can pass all ld tests, but it just blows up with a simple test > case: > > $ cat c.s > .global ifunc > .type ifunc, @gnu_indirect_function > .set ifunc, resolver > > resolver: > la.local $a0, impl > jr $ra > > impl: > li.w $a0, 42 > jr $ra > > .data > .global x > .type x, @object > x: > .dword ifunc > > $ cc c.s -shared > collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped > compilation terminated. > > So I think you'll at least need to build kernel/glibc/gcc using a ld > with your patches to make sure it works correctly. This is a bug, will be triggered: 1. a pointer point to a global ifunc, 2. compiling into a shared dynamic library. We will fix and test this issue soon.