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

[Jason Molenda via lldb-commits]

Ah, no.  Pavel suggested that the unwind plan unittests should be turned into FileCheck tests, and then Davide suggested that he'd heard unwind testing is difficult (he was conflating the unwind sources -> UnwindPlan IR conversions and the runtime use of UnwindPlans to walk the stack & find spilled registers), so he thought that this FileCheck could help there.  I was clarifying that (1) I don't want the existing tests I wrote changed out of unittests, and (2) FileCheck does not help the actually difficult part of testing the unwinder at all.  I provided an example of why this was difficult, outlining the possible approaches, and saying that if you were doing it today, you would need to do it with hand written assembly, and you suggested that a process mock style approach would be awesome, which was one of the approaches I described in my original email.

> On Feb 12, 2018, at 2:18 PM, Zachary Turner <zturner at google.com> wrote:
> 
> Sure I don’t think anyone disputes that, but I thought we were discussing an ideal end state
> On Mon, Feb 12, 2018 at 1:31 PM Jason Molenda <jmolenda at apple.com> wrote:
> 
> 
> > On Feb 12, 2018, at 12:59 PM, Zachary Turner <zturner at google.com> wrote:
> >
> >
> >
> > On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda <jmolenda at apple.com> wrote:
> >>
> >>
> >> > 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:
> >> >
> >> > 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.
> >
> > I'm saying we shouldn't need a live process (and in fact we can test it better if we don't rely on a live process, since we can write tests that run anywhere).
> 
> 
> Yes, as we've all agreed many times for years, a ProcessMock style Process plugin which can fake up state from a yaml file would be a great addition -- and for the unwind tests, we need a way to provide symbolic information and possibly even eh_frame information from the "binaries", and maybe even a way to construct the yaml representation from an actual debug session.  No one is disagreeing with this.
> 
> But the fact that no one has had time to develop this plugin means that if I want to write an unwind test today, I either need to allocate time to write the above infrastructure first, or write the test given the tools we have available to us today.
> 
> An unwind test that only runs on x86_64, or even only runs on x86_64 Darwin, is not ideal, but it is much better than no test at all especially in the world of buildbots that can flag a problem with a change right away.
> 
> J