mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Timo Teras <timo.teras@iki.fi>
To: Rich Felker <dalias@libc.org>
Cc: Ariadne Conill <ariadne@dereferenced.org>, musl@lists.openwall.com
Subject: Re: [musl] option to enable eh_frame
Date: Sun, 18 Jul 2021 09:09:22 +0300	[thread overview]
Message-ID: <20210718090922.635b96f8@vostro> (raw)
In-Reply-To: <20210717235635.GI13220@brightrain.aerifal.cx>

On Sat, 17 Jul 2021 19:56:36 -0400
Rich Felker <dalias@libc.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

  parent reply	other threads:[~2021-07-18  6:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-16  9:16 Timo Teras
2021-07-16 15:57 ` Rich Felker
2021-07-16 22:06   ` Ariadne Conill
2021-07-17  0:41     ` Rich Felker
2021-07-17  1:08       ` Ariadne Conill
2021-07-17  1:10         ` Érico Nogueira
2021-07-17  7:24         ` Laurent Bercot
2021-07-18  8:16       ` Timo Teras
2021-07-17  7:33   ` Timo Teras
2021-07-17 10:38     ` Timo Teras
2021-07-17 13:25     ` Rich Felker
2021-07-17 15:40       ` Timo Teras
2021-07-17 16:09         ` Rich Felker
2021-07-17 19:52           ` Ariadne Conill
2021-07-17 23:56             ` Rich Felker
2021-07-18  1:40               ` Ariadne Conill
2021-07-18  2:23                 ` Ariadne Conill
2021-07-18  6:09               ` Timo Teras [this message]
2021-07-18  7:20                 ` Timo Teras
2021-07-24 23:45                   ` Fangrui Song
2022-04-17 19:50     ` Fangrui Song

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=20210718090922.635b96f8@vostro \
    --to=timo.teras@iki.fi \
    --cc=ariadne@dereferenced.org \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).