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 1FD583858D32 for ; Tue, 26 Jul 2022 11:43:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1FD583858D32 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 AQAAf9AxaeBD099iDKU5AA--.27748S2; Tue, 26 Jul 2022 19:42:59 +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> From: Lulu Cheng Message-ID: <93f7b58a-d7a7-543a-21e1-19d237593426@loongson.cn> Date: Tue, 26 Jul 2022 19:42:59 +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: <25a7d2fcac8194083e58ed960eaf0f42dafc0559.camel@xry111.site> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID: AQAAf9AxaeBD099iDKU5AA--.27748S2 X-Coremail-Antispam: 1UD129KBjvJXoW7WrWfJFWkXw4xXr1xWw1rZwb_yoW8XF17p3 4ku398JF1UXw4Skw1Iya4xGw1F9a1SqFyYkryFg34FyFsrGFyfAFWxt3s8Gas8GF1a9w42 v3WIgrykC3WDA3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUva14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26r1I6r4UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j 6F4UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IY64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7Mxk0xIA0c2IEe2xFo4CEbIxv r21lc2xSY4AK6svPMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I 0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWU AVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcV CY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv 67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyT uYvjfU5WlkUUUUU X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Spam-Status: No, score=-6.9 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: 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 11:43:07 -0000 在 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? >> +  >> + 
  • The method for calling global functions changed from >> +  la.global + jirl to bl when complied add >> +  -fplt. > "from la.global + jirl to bl with -fno-plt and -mexplicit-relocs"? With > "-fplt" GCC 12 is already using bl, and with -mno-explicit-relocs > la.global is still used (if I read func-call-3.c correctly). I  should put '-fplt -mexplicit-relocs' here. >> + 
  • Changed ASM_PREFERRED_EH_DATA_FORMAT macro definition from >> +  WD_EH_PE_absptr to WD_EH_PE_pcrel | DW_EH_PE_sdata4. >> + 
    • > I don't think this paragraph is necessary because this change is purely > internal. > Should we indicate that our .eh_frame section format has changed? Thanks!