This is an archive of the discontinued LLVM Phabricator instance.

Improve UnwindLLDB with better detection for unwinding failures
ClosedPublic

Authored by tberghammer on Jul 3 2015, 8:38 AM.

Details

Summary

Improve UnwindLLDB with better detection for unwinding failures

Previously we accepted a frame as correct result if the PC pointed into an executable section of code. The isse with that approac is that if we calculated PC correctly but messed up the value of CFA then unwinding from the next fram will most likely fail.

With this change I modify the logic with keeping the requirement for PC to point to an executable section and also check that we can continue the unwind from the frame we calculated. If continuing from the frame calculated with the primary unwind plan isn't working then fall back to the fallback plan with the hope for a better frame (if the fallback plan won't help then we acceot the frame from the primary plan).

Diff Detail

Repository
rL LLVM

Event Timeline

tberghammer updated this revision to Diff 29029.Jul 3 2015, 8:38 AM
tberghammer retitled this revision from to Improve UnwindLLDB with better detection for unwinding failures.
tberghammer updated this object.
tberghammer added a reviewer: jasonmolenda.
tberghammer added a subscriber: lldb-commits.
jasonmolenda accepted this revision.Jul 3 2015, 12:47 PM
jasonmolenda edited edge metadata.

I'm fine with trying this approach. These heuristics for falling back to alternate unwind methods are tricky to get right; often the best approach is to live on them for a bit and pay close attention to the unwinder in complicated unwind situations.

The only question I have about the patch is the UnwindLLDB::CursorSP UnwindLLDB::GetOneMoreFrame (ABI* abi) method - you have 'return nullptr;' as a shortcut in a few places. Is that safe? Normally in a function that returns a shared pointer we'll write 'return CursorSP();' for this. I'm sure the nullptr gets converted to an empty shared pointer via a copy constructor, or something like that. I'm fine with coding it this way, just wanted to check if anyone knows it's OK.

This revision is now accepted and ready to land.Jul 3 2015, 12:47 PM

std::shared_ptr have an implicit constructor just for this purpose to make code simpler (without a typedef it would be odd to always write "return std::shared_ptr<Cursor>();")

constexpr shared_ptr( std::nullptr_t );
This revision was automatically updated to reflect the committed changes.