[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210716121625.38409b91@vostro>
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.
