From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) by sourceware.org (Postfix) with ESMTPS id A9AE7385840A for ; Fri, 4 Nov 2022 01:50:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A9AE7385840A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.alibaba.com X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R131e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046050;MF=rjiejie@linux.alibaba.com;NM=1;PH=DS;RN=3;SR=0;TI=SMTPD_---0VTuZ3ff_1667526630; Received: from 30.221.116.54(mailfrom:rjiejie@linux.alibaba.com fp:SMTPD_---0VTuZ3ff_1667526630) by smtp.aliyun-inc.com; Fri, 04 Nov 2022 09:50:31 +0800 Message-ID: Date: Fri, 4 Nov 2022 09:50:30 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: [PATCH v3] Support multiple .eh_frame sections To: Fangrui Song Cc: Nick Clifton , binutils@sourceware.org References: <20221102080112.33378-1-rjiejie@linux.alibaba.com> <20221103020409.37322-1-rjiejie@linux.alibaba.com> From: Jojo R In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00,ENV_AND_HDR_SPF_MATCH,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL 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: 在 2022/11/4 03:34, Fangrui Song 写道: > On Thu, Nov 3, 2022 at 3:26 AM Nick Clifton via Binutils > wrote: >> Hi Jojo, >> >>> This patch is based on MULTIPLE_FRAME_SECTIONS and EH_FRAME_LINKONCE, >>> it allows backend to enable this feature and use '--gc-sections' simply. >>> >>> * gas/dw2gencfi.h (TARGET_MULTIPLE_EH_FRAME_SECTIONS): New. >>> (MULTIPLE_FRAME_SECTIONS): Add TARGET_MULTIPLE_EH_FRAME_SECTIONS. >>> * gas/dw2gencfi.c (EH_FRAME_LINKONCE): Add TARGET_MULTIPLE_EH_FRAME_SECTIONS. >>> (is_now_linkonce_segment): Likewise. >>> (get_cfi_seg): Create relocation info between .eh_frame.* and .text.* section. >>> >>> * bfd/elf-bfd.h (elf_backend_can_make_multiple_eh_frame): New. >>> * bfd/elfxx-target.h (elf_backend_can_make_multiple_eh_frame): Likewise. >>> * bfd/elflink.c (_bfd_elf_default_action_discarded): Add checking for >>> elf_backend_can_make_multiple_eh_frame. >> >> Approved - please apply. >> >> Cheers >> Nick >> > Hi Jojo, is there a test demonstrating the handling of multiple > .eh_frame? Input .eh_frame or output .eh_frame? > > .eh_frame handling is known to be weird with --gc-sections but linkers > have gained support: > https://maskray.me/blog/2020-11-08-stack-unwinding#linker-perspective We want to encode another eh_frame format like arm, and based on seprated eh_frame sections :) > Since monolithic .eh_frame has been around for so long, some tools may > gain reliance on it and they will need to be fixed. > Also, it'd be nice to verify that .eh_frame_hdr and PT_GNU_EH_FRAME > creation is still correct. Thanks for your mention, it looks good for baremetal. .eh_frame_hdr or shared libs system like linux is not supported by now, we will append another patch later if we finished that.