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

[Zachary Turner via lldb-commits]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20180212/ddbb6751/attachment.html>