[PATCH] D90898: [libunwind] Unwind through aarch64/Linux sigreturn frame
Saleem Abdulrasool via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Jan 13 13:45:30 PST 2021
compnerd accepted this revision.
compnerd added a comment.
This revision is now accepted and ready to land.
In D90898#2384775 <https://reviews.llvm.org/D90898#2384775>, @rprichard wrote:
> In D90898#2379387 <https://reviews.llvm.org/D90898#2379387>, @compnerd wrote:
>
>> Could you add a bit of a comment explaining why the XOM case is not protected against?
>
> I think I can expand on the comment.
>
>> libunwind can be used for generating backtraces during regular execution (e.g. profiling) and crashing if the XOM is in use seems unfortunate.
>
> For profiling, I assume the unwind info needs to be accurate at every instruction? I know that's definitely not the case for AArch64 <https://bugs.llvm.org/show_bug.cgi?id=47142>, but I thought it's still only mostly-accurate on other archs? I don't *really* know that unwinding through a signal handler is important for Android, but I don't know how to rule it out either, and we do have a test for it <https://android.googlesource.com/platform/bionic/+/6fc751cca894fb496fb5d854260151bf443229ac/tests/stack_unwinding_test.cpp#114>. I think the test predated Android's libunwindstack unwinder. Maybe someone could be using `_Unwind_Backtrace` in a segfault handler, and that probably avoids the async-unwind-info problem most of the time. But I also don't think that's how third-party Android crash dumpers work.
Sure, though, libunwind is generic and is used outside of android as well, including other AArch64 targets, so we do need to consider those use cases while making changes.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D90898/new/
https://reviews.llvm.org/D90898
More information about the llvm-commits
mailing list