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.

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

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

Thanks,
Timo