diff options
author | Julian Lettner <jlettner@apple.com> | 2019-02-18 18:47:49 +0000 |
---|---|---|
committer | Julian Lettner <jlettner@apple.com> | 2019-02-18 18:47:49 +0000 |
commit | eb3bcc1c951039c7ab4656ef44e7e5deffe1ad92 (patch) | |
tree | f8bf5e754663ae4b5a5011c9e314d05fe5b9c109 /lldb/packages/Python/lldbsuite/test | |
parent | debaf4bd31a18265768aaf6485a87db7410ef1b7 (diff) | |
download | bcm5719-llvm-eb3bcc1c951039c7ab4656ef44e7e5deffe1ad92.tar.gz bcm5719-llvm-eb3bcc1c951039c7ab4656ef44e7e5deffe1ad92.zip |
[Sanitizer] On Darwin `__sanitizer_print_stack_trace` only prints topmost frame
In compiler-rt we have the notion of a `fast` and a `slow` stack
unwinder. Darwin currently only supports the fast unwinder.
From reading the code, my understanding is that
`BufferedStackTrace::Unwind` can be called with `bp=0, stack_top=0,
stack_bottom=0, request_fast_unwind=false`. If
`request_fast_unwind=true`, then we alos need to supply bp, stack_top,
and stack_bottom.
However, `BufferedStackTrace::Unwind` uses
`StackTrace::WillUseFastUnwind` which will adapt `request_fast_unwind`
if the requested unwinder is not supported. On Darwin, the result is
that we don't pass actual values for bp, stack_top, and stack_bottom,
but end up using the fast unwinder. The tests then fail because we only
print the topmost stack frame.
This patch adds a check to `WillUseFastUnwind` at the point of usage to
avoid the mismatch between `request_fast_unwind` and what `Unwind`
actually does. I am also interested in cleaning up the
`request_fast_unwind` machinery so this patch just the simplest thing
possible so I can enable the tests.
Reviewers: vitalybuka, vsk
Differential Revision: https://reviews.llvm.org/D58156
llvm-svn: 354282
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test')
0 files changed, 0 insertions, 0 deletions