Re: [musl] [PATCH] Add options to configure script to control frame pointer omission and EH unwind information

[Alastair Houghton <ahoughton@apple.com>]

> On 29 Jul 2023, at 06:25, alice <alice@ayaya.dev> wrote:
> 
> 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

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.

Kind regards,

Alastair.