From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 563583858D32 for ; Tue, 26 Jul 2022 12:01:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 563583858D32 Received: from localhost.localdomain (xry111.site [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 69CA966814; Tue, 26 Jul 2022 08:01:16 -0400 (EDT) Message-ID: Subject: Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support From: Xi Ruoyao To: Lulu Cheng , gcc-patches@gcc.gnu.org Cc: xuchenghua@loongson.cn, Wang Xuerui Date: Tue, 26 Jul 2022 20:01:14 +0800 In-Reply-To: <93f7b58a-d7a7-543a-21e1-19d237593426@loongson.cn> References: <20220726072119.2910839-1-chenglulu@loongson.cn> <25a7d2fcac8194083e58ed960eaf0f42dafc0559.camel@xry111.site> <93f7b58a-d7a7-543a-21e1-19d237593426@loongson.cn> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.3 MIME-Version: 1.0 X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FROM_SUSPICIOUS_NTLD, LIKELY_SPAM_FROM, PDS_OTHER_BAD_TLD, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2022 12:01:22 -0000 On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote: > =E5=9C=A8 2022/7/26 =E4=B8=8B=E5=8D=885:44, Xi Ruoyao =E5=86=99=E9=81=93: > >=20 > > > +=C2=A0 whether the la.* macro instructions will be gene= rated when > > > +=C2=A0 loading symbolic addresses. > > > +=C2=A0 This feature requires binutils version 2.40 or later. If you = want to use the > > > +=C2=A0 older version of bintuils, add compiler parameters > > > +=C2=A0 -mno-explicit-relocs at compile time. > > Does it mean we need to make sure GCC 13 released after binutils-2.40? > > binutils-2.39 release branch is already created and it's now explicitly > > "no new feature" so a backport seems impossible... >=20 > Do you think it's okay if we don't write Binutils version restrictions > now and wait until Binutils code is released to annotate? I think you can just put Binutils 2.40 here. GCC 13 will be released in Apr or May 2023, and Binutils-2.40 will be released in Jan or Feb 2023 (if no bad thing happens), so my previous concern is actually not a problem. Maybe we can add a check in gcc/configure.ac to see if gcc_cv_ld supports %got_pc_hi20 and adjust the default for -m[no]-explicit-relocs? >=20 > Should we indicate that our .eh_frame section format has changed? I don't really understand C++ exception handling, so: does the change breaks something? For example, if foo links to libbar, libbar is built with GCC 12 (or vice versa), would an exception thrown from libbar properly caught by foo? Generally changes.html is for compiler users (instead of developers), and I believe at least 90% of users (including I) don't know the potential consequences from a .eh_frame format change. So it's better to describe the breakage and possible workaround here. If nothing will be broken, we can just skip the change in changes.html. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University