mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Timo Teras <timo.teras@iki.fi>
Cc: musl@lists.openwall.com
Subject: Re: [musl] option to enable eh_frame
Date: Fri, 16 Jul 2021 11:57:35 -0400	[thread overview]
Message-ID: <20210716155735.GC13220@brightrain.aerifal.cx> (raw)
In-Reply-To: <20210716121625.38409b91@vostro>

On Fri, Jul 16, 2021 at 12:16:25PM +0300, Timo Teras wrote:
> Hi,
> 
> This has been discussed few times, and I know there are arguments also
> not to do this. But at this time we at Alpine think the reasons to keep
> eh_frame outweight the reasons to not include it.

As explained on the tracker issue, what you'r requesting is a patch to
make a configure option that changes the public interface contract of
musl, making different interface contract profiles. This is not a
change to be made lightly. There has been *some* consideration in the
past for accepting this kind of option in the opposite direction:
omitting large functionality that might not be needed in some contexts
(like iconv), but where the default is to have it and omitting it is
just a choice particular users can make for working in a very
constrained environment. But if you add the option, you're essentially
making "having it" the de facto default, even if configure has
"disable" as the default. Once something is using it, there's an
implicit requirement to have it.

Honestly, proposing that it always be available (or configurable but
on by default) would be less controversial than a configure option.
I'd still be against it but at least some of the badness is gone.

> Main arguments against .eh_frame being:
> 
> 1) Having .eh_frame makes it seem like C++ exception throwing works
>    through C-library functions (e.g. throwing exception form qsort
>    callback to return over qsort back to application).
> 
>    Counter arguments:
>    - C++ exceptions is just one way to jump through musl functions.
>      E.g. setjmp/longjmp can do that just fine even without .eh_frame
> 
> 2) Having application unwind itself for backtrace printing purposes
>    especially in signal handler is bad. This is agreed, but there's
>    still other cases when unwinding is good for debugging, and other
>    reasons. The fix for this root cause is to remove the unwinding from
>    signal handlers.

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.

> Arguments to have .eh_frame:
>  - It allows debugging things even if musl-dbg is not or cannot be
>    installed for some reason (e.g. gdb, valgrind), or is no longer
>    available
>  - libunwind/libexecinfo will start to work and give meaningful
>    backtraces

This is explicitly a reason not to. backtrace() considered harmful.

>  - Continuous kernel based profiling (e.g. perf record -g dwarf) will
>    work

This already works if you have debug info.

> Given that the main arguments against are either making UB crash, or
> not the best fix, and keeping eh_frame enables useful features to work,
> I think it would make sense to allow enabling it.
> 
> Please consider the the attached patch to make it a configure option to
> enable keeping eh_frame (defaulting still to not keeping it).

You can solve this problem just as well for the things you want to
have work by including the (part of) the debug info you want in the
main libc.so binary: .debug_frame. Of course I can't stop Alpine from
doing it in a different way locally, but I would strongly recommend
you do that rather than making a contract that diverges from musl.

Rich

  reply	other threads:[~2021-07-16 15:57 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 [this message]
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
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=20210716155735.GC13220@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    --cc=timo.teras@iki.fi \
    /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).