[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 18 Jul 2021 09:09:22 +0300
From: Timo Teras <timo.teras@....fi>
To: Rich Felker <dalias@...c.org>
Cc: Ariadne Conill <ariadne@...eferenced.org>, musl@...ts.openwall.com
Subject: Re: option to enable eh_frame
On Sat, 17 Jul 2021 19:56:36 -0400
Rich Felker <dalias@...c.org> wrote:
> Having something as part of the loadable program segment means it's
> always available, not strippable or missing if debug packages are not
> installed. Having it be in a non-load section (not segment) means
> it's metadata about the binary for tooling (e.g. debugger) usage, to
> be accessed by reading the file(s) not runtime data structures mapped
> in memory. From my perspective, the reason for it to be the latter is
> to reflect that this is debug info available only in a debug
> environment, not part of musl's runtime interfaces.
So basically if I understand correctly:
1. You want all musl libraries to have equal (or forward-going)
expectation of what is included in the LOAD segments.
2. Even if users expect/rely on debug_frame it's acceptable because
that is strippable and shows this is "optional" or "debug" feature.
This does makes sense.
However, I thought the primary case was the unwinding through C-library
and backtrace(). And trying distro to force patch packages instead of
having those work. Just noting this because .debug_frame might make us
not notice some of the "badness".
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.
Though, I still hope to see the time and a way having .eh_frame would
acceptable. Is there anything I could implement or do to make it
acceptable? For me it's presence is not "contract" commitment because
it's not ABI feature. It only affects the functions we have not
promised to implement. As explained just keeping .debug_frame is
similar "de facto contract" to distro users. The fact whether it's not
strippable or not does not matter, what matters is what is being
shipped by default.
Timo
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.
