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 2A8193858029 for ; Tue, 26 Jul 2022 13:27:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2A8193858029 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.52] (unknown [10.20.4.52]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9BxI9Cg699ieNM5AA--.17871S2; Tue, 26 Jul 2022 21:26:56 +0800 (CST) Subject: Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support To: Xi Ruoyao , gcc-patches@gcc.gnu.org Cc: xuchenghua@loongson.cn, Wang Xuerui References: <20220726072119.2910839-1-chenglulu@loongson.cn> <25a7d2fcac8194083e58ed960eaf0f42dafc0559.camel@xry111.site> <93f7b58a-d7a7-543a-21e1-19d237593426@loongson.cn> From: Lulu Cheng Message-ID: <653cf06d-da9c-419d-8c70-55962163b155@loongson.cn> Date: Tue, 26 Jul 2022 21:26:56 +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: Content-Language: en-US X-CM-TRANSID: AQAAf9BxI9Cg699ieNM5AA--.17871S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Wry3AF4UCw1UZr1rGw47twb_yoW8ZrWUpa yjkan8JF1vqr4furs7A3WIkr1Fvan5JFy5Krykt34jvr15KF95ArZ3tFZYkan5ZF4ava12 va1SgF97Cas8Z3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv214x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26r4j6ryUM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j 6F4UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2 jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwACjI8F5VA0II 8E6IAqYI8I648v4I1l7480Y4vEI4kI2Ix0rVAqx4xJMxk0xIA0c2IEe2xFo4CEbIxvr21l c2xSY4AK6svPMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWU twCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAF wI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa 7VUb_gA7UUUUU== X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, HTML_MESSAGE, 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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 13:27:08 -0000 在 2022/7/26 下午8:01, Xi Ruoyao 写道: > On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote: > >> 在 2022/7/26 下午5:44, Xi Ruoyao 写道: >>>> +  whether the la.* macro instructions will be generated when >>>> +  loading symbolic addresses. >>>> +  This feature requires binutils version 2.40 or later. If you want to use the >>>> +  older version of bintuils, add compiler parameters >>>> +  -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... >> 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? I think this is a good way, I'll look at adding a check. >> 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. > > I'm looking to see if I can find a test that can verify the compatibility or incompatibility before and after the modification. Thanks!:-)