Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 16 Jul 2021 12:16:25 +0300
From: Timo Teras <>
Subject: option to enable eh_frame


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.

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.

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
 - libunwind/libexecinfo will start to work and give meaningful
 - Continuous kernel based profiling (e.g. perf record -g dwarf) will

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).


View attachment "eh-frame.patch" of type "text/x-patch" (5166 bytes)

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.