From: Alastair Houghton <email@example.com>
Subject: Re: [musl] [PATCH] Add options to configure script to control frame pointer omission and EH unwind information
Date: Mon, 31 Jul 2023 15:15:30 +0100 [thread overview]
Message-ID: <78023E0A-E006-4F36-98B2-9C8894C5B7EF@apple.com> (raw)
> On 29 Jul 2023, at 06:25, alice <firstname.lastname@example.org> wrote:
> i believe the proposed change, and the rationale for it, had already been
> thoroughly discussed and rejected in
Thanks for the link. That was an interesting read.
> there is no intent to allow 'runtime use' of this data (i.e. allow backtraces),
> outside of what already works with an external debugger.
It’s worth noting (and I think the Alpine folks did mention this in the thread you highlighted) that external debuggers don’t work inside Docker containers, at least by default, and that that cluster operators are unlikely to want to make the changes that would be required to fix that because they create security holes.
At the same time, generating backtraces in e.g. assertion failure routines or from a C++ unhandled exception handler can be a useful thing to do and is not nearly as risky as trying to do that from a SEGV handler. With no EH frame information and no frame pointers, those backtraces are going to stop the moment they hit musl’s code. Maybe that’s OK — there aren’t that many things in the C library that involve calling out to user code anyway.
> unrelatedly (to the prior rejection), i believe these days there has been work
> on the SFrame format (as opposed to EH), to allow easier backtracing (they
> aren't mutually exclusive). maybe that is better to build on these days?
As I understand it that’s a Linux kernel thing, and not really applicable outside of that context.
What I was mostly trying to do is get (LLVM) libunwind’s tests to pass out of the box, without having to disable things for musl. Maybe I just disable those tests for now.
prev parent reply other threads:[~2023-07-31 14:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-28 11:13 Alastair Houghton
2023-07-29 5:25 ` alice
2023-07-31 14:15 ` Alastair Houghton [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).