From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [IPv6:2001:470:683e::1]) by sourceware.org (Postfix) with ESMTPS id 318313858D35 for ; Sat, 21 Oct 2023 08:42:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 318313858D35 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 318313858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:683e::1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697877746; cv=none; b=xthyWfd0cqbnj0QwcD1X3TXpucHJBJZqP949Zqu357Bg1UvpNYCy+be5mwYYwIw/J1p0jIuZPrd05huCncKyp0JhnSLA1pYrbnabSOHNKWe5JrBLOI7mgnxTa540sTjlCGyp+QDGSfYvEiJ5nqGwBshmH1re8KbtJspYx/hOmHI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697877746; c=relaxed/simple; bh=MoTZdrSQwpjD0gn5M+h1Xa69liEY3QJWfQDW9Xe9JrU=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=mk6lI57/Wqcuk9ZL+JqGp3qyOm6InB0xlLe0RTp44oQfooKDAxVzycbeYc4W3gXr0XiMhcBvXaF4hiEfCib/t6kbwJzy4dLNk3Tom8aettIs1+EdrLs5/e2xmMA+j1l3lnAF0Cc8syGTe72DHoc5J6zIt3fRT8TDAc3X9XaW5ms= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1697877731; bh=MoTZdrSQwpjD0gn5M+h1Xa69liEY3QJWfQDW9Xe9JrU=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=krRXiIdoCYIjpqztkQwDmprNMPupEHXV1HXvsuGGixtHCFn9mXNjx3acardwbxbr4 flg573aaUBrn6ZIiXVtKSV6Dt28rv/an9jz/LeIBJ/+7dPgf6NYCjiyTJox1oLGN9Y W9822oXYZpnmyZ4Nibkrp6PHiC1j/QFU5uAmnMnM= Received: from [127.0.0.1] (unknown [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 1864E66B85; Sat, 21 Oct 2023 04:42:09 -0400 (EDT) Message-ID: 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 From: Xi Ruoyao To: chenglulu , gcc-patches@gcc.gnu.org Cc: i@xen0n.name, xuchenghua@loongson.cn, mengqinggang Date: Sat, 21 Oct 2023 16:42:07 +0800 In-Reply-To: <0a7f962f-8a2b-d6e3-1e32-3675c13abefe@loongson.cn> References: <20231019140300.50323-1-xry111@xry111.site> <20231019140300.50323-3-xry111@xry111.site> <0a7f962f-8a2b-d6e3-1e32-3675c13abefe@loongson.cn> Autocrypt: addr=xry111@xry111.site; prefer-encrypt=mutual; keydata=mDMEYnkdPhYJKwYBBAHaRw8BAQdAsY+HvJs3EVKpwIu2gN89cQT/pnrbQtlvd6Yfq7egugi0HlhpIFJ1b3lhbyA8eHJ5MTExQHhyeTExMS5zaXRlPoiTBBMWCgA7FiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQrKrSDhnnEOPHFgD8D9vUToTd1MF5bng9uPJq5y3DfpcxDp+LD3joA3U2TmwA/jZtN9xLH7CGDHeClKZK/ZYELotWfJsqRcthOIGjsdAPuDgEYnkdPhIKKwYBBAGXVQEFAQEHQG+HnNiPZseiBkzYBHwq/nN638o0NPwgYwH70wlKMZhRAwEIB4h4BBgWCgAgFiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwwACgkQrKrSDhnnEOPjXgD/euD64cxwqDIqckUaisT3VCst11RcnO5iRHm6meNIwj0BALLmWplyi7beKrOlqKfuZtCLbiAPywGfCNg8LOTt4iMD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.1 MIME-Version: 1.0 X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sat, 2023-10-21 at 15:32 +0800, chenglulu wrote: > > +=C2=A0 /* If we are performing LTO for a final link, and we have the l= inker > > +=C2=A0=C2=A0=C2=A0=C2=A0 plugin so we know the resolution of the symbo= ls, then all GOT > > +=C2=A0=C2=A0=C2=A0=C2=A0 references are binding to external symbols or= preemptable symbols. > > +=C2=A0=C2=A0=C2=A0=C2=A0 So the linker cannot relax them.=C2=A0 */ > > +=C2=A0 return (in_lto_p > > + =C2=A0 && !flag_incremental_link >=20 > I don=E2=80=99t quite understand this condition "!flag_incremental_link".= Can=20 > you explain it? Others LGTM. >=20 > 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=3Dnolto-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. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University