From: Jojo R <rjiejie@linux.alibaba.com>
To: Fangrui Song <i@maskray.me>
Cc: Nick Clifton <nickc@redhat.com>, binutils@sourceware.org
Subject: Re: [PATCH v3] Support multiple .eh_frame sections
Date: Fri, 4 Nov 2022 09:50:30 +0800 [thread overview]
Message-ID: <d4936426-e409-3bba-e3d7-c52fa0eb75d5@linux.alibaba.com> (raw)
In-Reply-To: <DS7PR12MB57653A2E86C6779B24889E51CB389@DS7PR12MB5765.namprd12.prod.outlook.com>
在 2022/11/4 03:34, Fangrui Song 写道:
> On Thu, Nov 3, 2022 at 3:26 AM Nick Clifton via Binutils
> <binutils@sourceware.org> 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.
prev parent reply other threads:[~2022-11-04 1:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-29 7:48 [PATCH] " Jojo R
2022-08-01 11:10 ` Nick Clifton
2022-08-02 7:23 ` Jojo R
2022-11-02 8:01 ` [PATCH v2] " Jojo R
2022-11-02 12:21 ` Nick Clifton
2022-11-03 2:11 ` Jojo R
2022-11-03 2:04 ` [PATCH v3] " Jojo R
2022-11-03 10:26 ` Nick Clifton
2022-11-03 19:34 ` Fangrui Song
[not found] ` <DS7PR12MB57653A2E86C6779B24889E51CB389@DS7PR12MB5765.namprd12.prod.outlook.com>
2022-11-04 1:50 ` Jojo R [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d4936426-e409-3bba-e3d7-c52fa0eb75d5@linux.alibaba.com \
--to=rjiejie@linux.alibaba.com \
--cc=binutils@sourceware.org \
--cc=i@maskray.me \
--cc=nickc@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).