From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 29408385840C for ; Mon, 23 Oct 2023 00:56:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 29408385840C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 29408385840C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=114.242.206.163 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698022610; cv=none; b=hu2d4VQ5hu4vZfUyKuGGcz+hUJh9o6CFTVyNYBqrhBZhUTKINct/eeW893Ob4fQ5Ff+9sWBxlnxVIMFLbcGBf/8rroX5GvS+4cvbvJWMaU5zq9JB7qNJnvh5na6/y2hm0s9PY1z5qpjQ1KcwdbNSWP03qThwCVMT1ezdLiBU6GU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698022610; c=relaxed/simple; bh=AeMTQWG/kuEt4xNXiy+6vDDce5rWoz/J3cJPZsFtJjo=; h=Subject:To:From:Message-ID:Date:MIME-Version; b=p+22YLFNu2g1+hrAiEvRhrWD4Sccx/NvVnDYTljPJaGxhrAZ2nPW4D7+YWciHaGrtfVDTf4NFT2EQzFnOsCl0A9sW22HOah6iY1i3tJIJ0p2jQoczSrd4YmhZ1tKg8tN3g0UZSJTaW5/MyQn4pnAbUwxDRS5Vgbh6oFI3fDQU+M= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from loongson.cn (unknown [10.20.4.107]) by gateway (Coremail) with SMTP id _____8CxtPDLxDVl59IzAA--.36128S3; Mon, 23 Oct 2023 08:56:43 +0800 (CST) Received: from [10.20.4.107] (unknown [10.20.4.107]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Dx_y_JxDVlF6QuAA--.33287S3; Mon, 23 Oct 2023 08:56:42 +0800 (CST) Subject: Re: [PATCH 2/5] LoongArch: Use explicit relocs for GOT access when -mexplicit-relocs=auto and LTO during a final link with linker plugin To: Xi Ruoyao , gcc-patches@gcc.gnu.org Cc: i@xen0n.name, xuchenghua@loongson.cn, mengqinggang References: <20231019140300.50323-1-xry111@xry111.site> <20231019140300.50323-3-xry111@xry111.site> <0a7f962f-8a2b-d6e3-1e32-3675c13abefe@loongson.cn> From: chenglulu Message-ID: <524f9e12-df3e-e51c-a83c-c580eced22f9@loongson.cn> Date: Mon, 23 Oct 2023 08:56:41 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8Dx_y_JxDVlF6QuAA--.33287S3 X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBj93XoW7Gw1rJr4UCr45XF48uryxtFc_yoW8JrW7pr Z5CrWqvr98GF4rAw18Cw48AF45ZFs7t3WUCr1vgryvy39Fqr9Fgw15twnIg3Wktrs7Cw15 Xry2yanxur1rXagCm3ZEXasCq-sJn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUvYb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r106r15M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv6xkF7I0E14v2 6r4j6r4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYIkI8VC2zVCFFI0UMc 02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAF wI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4 CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG 67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMI IYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E 14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJV W8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07j8yCJU UUUU= X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_NONE,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 List-Id: 在 2023/10/21 下午4:42, Xi Ruoyao 写道: > On Sat, 2023-10-21 at 15:32 +0800, chenglulu wrote: >>> +  /* If we are performing LTO for a final link, and we have the linker >>> +     plugin so we know the resolution of the symbols, then all GOT >>> +     references are binding to external symbols or preemptable symbols. >>> +     So the linker cannot relax them.  */ >>> +  return (in_lto_p >>> +   && !flag_incremental_link >> I don’t quite understand this condition "!flag_incremental_link". Can >> you explain it? Others LGTM. >> >> Thanks. > If we have two (or several) .o files containing LTO bytecode, GCC > supports "LTO incremental linking" with: > > gcc a.o b.o -o ab.o -O2 -flto -flinker-output=nolto-rel > > The resulted ab.o will include data and code in a.o and b.o, but it > contains machine code instead of LTO bytecode. Now if ab.o refers to an > external symbol c, the linker may relax "la.global c" to "la.local c" > (if ab.o is linked together with another file c.o which contains the > definition of c) or not. As we cannot exclude the possibility of a > relaxation on la.global for incremental linking, just emit la.global and > let the linker to do the correct thing. > I have no problem, thank you!