[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 29 Jul 2023 05:25:25 +0000
From: "alice" <alice@...ya.dev>
To: <musl@...ts.openwall.com>
Subject: Re: [PATCH] Add options to configure script to control frame
pointer omission and EH unwind information
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
https://www.openwall.com/lists/musl/2021/07/16/1
(not exactly the same, and the above isn't as fine grained, but the core of it
is identical)
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,
>
> Alastair.
>
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.
