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 2EAF7385829F for ; Thu, 28 Jul 2022 02:59:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2EAF7385829F 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 AQAAf9AxaeCO++Fih_o9AA--.33614S2; Thu, 28 Jul 2022 10:59:26 +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: Date: Thu, 28 Jul 2022 10:59:26 +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: AQAAf9AxaeCO++Fih_o9AA--.33614S2 X-Coremail-Antispam: 1UD129KBjvJXoW7AF4fur45XF1xZF4UWw1xKrg_yoW8uFy3pF y5Aan8KrZ8WF1S93WkCw4jkF4fJF1DAryUWFySgw43K345XF95JrsIgFZ8Ar1rGr97XryY va17trs7CF98ZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUva14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j 6r4UJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26F 4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487McIj6xIIjxv20xvE14v26r1j6r18McIj 6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lF7I21c 0EjII2zVCS5cI20VAGYxC7Mx8GjcxK6IxK0xIIj40E5I8CrwCYjI0SjxkI62AI1cAE67vI Y487MxkIecxEwVCm-wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s 026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_ JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20x vEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280 aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyT uYvjfUoXo2UUUUU X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, BODY_8BITS, 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: Thu, 28 Jul 2022 02:59:32 -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 写道: >>> 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. > > The ASM_PREFERRED_EH_DATA_FORMAT macro before and after modification is as follows:  #define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \ -  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_absptr) +  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4) Use the following tests to describe the effect of modifying this macro on the generated assembly code： #include #include using namespace std; int main() { 　　try { 　　throw 1; 　　} 　　catch (int i) 　　{ 　　　　cout << i << endl; 　　} } The main comparisons related to the eh_frame section are as follows： 　　　　　　 OLD NEW .LFB1997 = . | .LFB1780 = . .cfi_startproc | .cfi_startproc .cfi_personality 0x80,DW.ref.__gxx_personality_v0 | .cfi_personality 0x9b,DW.ref.__gxx_personality_v0 .cfi_lsda 0,.LLSDA1997 | .cfi_lsda 0x1b,.LLSDA1780 If the assembly file generated by the new gcc is compiled with the binutils of version 2.38, the following error will be reported: test.s:74: Error: invalid or unsupported encoding in .cfi_personality test.s:75: Error: invalid or unsupported encoding in .cfi_lsda So I think I should judge whether binutils supports this encoding when gcc is configured, and then choose how to define macro ASM_PREFERRED_EH_DATA_FORMAT.