[Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion

[Jason Molenda via lldb-commits]

> On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator <reviews at reviews.llvm.org> wrote:
> 
> zturner added a comment.
> 
> In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote:
> 
>> 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.
> 
> 
> That's exactly the type of thing that FileCheck tests work best for.  I'm not sure why you're saying that unittests are better than FileCheck tests for this scenario.


I'm saying that the unittests here are entirely appropriate, and that rewriting existing tests in FileCheck style doesn't make any sense to me.  If people want to write new tests using that style, that's fine I guess, but I wrote these tests for a part of lldb that I maintain and I'd prefer to keep them as-is.


> 
>> 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 don't think we'd necessarily need a live register context or stack memory.  A mock register context and stack memory should be sufficient, with an emulator that understands only a handful of instructions.


That's ... exactly what I said?  That we need to mock up memory and registers and symbols, or have a corefile and binary, or have hand written assembly routines that set up a particular stack and an SB API test that tries to backtrace out of it with a live process.  After the inferior process state has been constructed/reconstituted, is the unwinder capable of walking the stack or finding spilled registers by following the correct UnwindPlans.  This is right in the wheelhouse of SB API testing.

J