From: "alice" <email@example.com>
Subject: Re: [musl] [PATCH] Add options to configure script to control frame pointer omission and EH unwind information
Date: Sat, 29 Jul 2023 05:25:25 +0000 [thread overview]
Message-ID: <CUEEMUQVTGE4.1U9H8G982URS8@sumire> (raw)
On Fri Jul 28, 2023 at 11:13 AM UTC, Alastair Houghton wrote:
> Hi there,
> Musl currently disables frame pointers and (except in debug builds) also
> disables the emission of EH unwind information, the latter presumably in an
> effort to save space. The downside of doing both of these things is that it
> makes it impossible for code to generate reasonable run-time backtraces, since
> without frame pointers the only way to do a stack walk is the EH unwind data,
> which has been removed.
> These defaults are probably fine for most people, but not everybody wants to
> build in this configuration, and it would be better to offer some reasonable
> options here, I think. I attach a patch that adds options to the configure
> script that allow users of Musl to choose
> * Whether to include frame pointers.
> * Whether to include EH unwind tables, and if so whether they should support
> asynchronous unwind or not (asynchronous unwind generates more data in the
> tables, since the compiler isn’t allowed to make assumptions about which code
> could throw).
> Note that the existing comment in the configure script about the DWARF tables
> is slightly misleading; the options the configure script uses are to do with
> EH unwind data (which is for exception handling, in languages that support it,
> as well as for runtime backtracing), and not with DWARF unwind data. The two
> do potentially share some sections and the EH data is stored using DWARF as a
> format, but it *isn’t* debug information - it’s there for language runtime and
> library use.
i believe the proposed change, and the rationale for it, had already been
thoroughly discussed and rejected in
(not exactly the same, and the above isn't as fine grained, but the core of it
the core of it is really in (quoting Rich):
> The debugger already can do debugging/unwinding because it has access
> to the debug information (if you've installed it) and there is a
> clear, understood-by-users contract that this information is not an
> inherent part of the program but something optional for external
> debugging tools only.
>> - libunwind/libexecinfo will start to work and give meaningful backtraces
> This is explicitly a reason not to. backtrace() considered harmful.
there is no intent to allow 'runtime use' of this data (i.e. allow backtraces),
outside of what already works with an external debugger.
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?
> Kind regards,
next prev parent reply other threads:[~2023-07-29 5:25 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 [this message]
2023-07-31 14:15 ` Alastair Houghton
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).