jasonmolenda added a comment. No, the unwind unittests that exist today should stay written as unit tests. These are testing the conversion of native unwind formats -- for instance, eh_frame, compact unwind, or instruction analysis -- into the intermediate UnwindPlan representation in lldb. They are runtime invariant, unit tests are the best approach to these. If there were anything to say about these, it would be that we need more testing here - armv7 (AArch32) into UnwindPlan is not tested. eh_frame and compact_unwind into UnwindPlan is not tested.
The part of unwind that is difficult to test is the runtime unwind behavior, and FileCheck style tests don't make that easier in any way. We need a live register context, stack memory, symbols and UnwindPlans to test this correctly -- we either need a full ProcessMock with SymbolVendorMock etc, or we need corefiles, or we need tests with hand-written assembly code. I'm leaning towards starting to write C test cases with hand written assembly routines that set up their stacks in unusual ways to test the unwinder, I've written unwind testsuites in the past in this way and it works well but it does mean that you need to be on the arch (and possibly even the OS) that the test is written in -- bots will show the failures for everyone after a commit goes in, at least. But these will be written as SB API tests. https://reviews.llvm.org/D43048 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
