Date: Fri, 16 Jul 2021 12:16:25 +0300 From: Timo Teras <timo.teras@....fi> To: musl@...ts.openwall.com Subject: option to enable eh_frame 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 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.