[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 24 Jul 2021 16:45:52 -0700
From: Fangrui Song <i@...kray.me>
To: musl@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>,
Ariadne Conill <ariadne@...eferenced.org>
Subject: Re: option to enable eh_frame
On 2021-07-18, Timo Teras wrote:
>On Sun, 18 Jul 2021 09:09:22 +0300
>Timo Teras <timo.teras@....fi> wrote:
>
>> I do have some technical reasons why I'd prefer .eh_frame (getting it
>> on core dumps). Fortunately I need these from development boxes where
>> I can have custom build for internal use only. So if .debug_frame is
>> needed for peace, then so be it.
>
>I'm trying to implement this currently, and have two observations:
>
>1) musl.so seems to have .eh_frame even with default options currently.
>GCC insists generating it for the PLT. Though otherwise it's empty.
>This is on gcc 10.3.1.
ld can generate .eh_frame pieces for PLT entries on x86.
GNU ld and gold have implemented --ld-generated-unwind-info. It was
proposed in 2011 in
https://sourceware.org/bugzilla/show_bug.cgi?id=12570 At that time gdb
could not unwind from the middle of a PLT entry. (It can do that now.)
(ld.lld doesn't have the feature. Considering that only asynchronous
unwinding requests in the PLT code sequence may benefit from the
feature, this is of very low value.
It adds complexity due to breaking phase ordering in a linker.)
>2) .debug_frame is 109944 bytes, while .eh_frame_hdr + .eh_frame is
>83832. The size difference seems to be because of CIE entries not being
>merged for .debug_frame.
Yep, ld can optimize .eh_frame_hdr + .eh_frame . .debug_frame is
unoptimized.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
