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 <jmole...@apple.com> wrote:
> > On Feb 12, 2018, at 12:59 PM, Zachary Turner <ztur...@google.com> wrote:
> > On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda <jmole...@apple.com>
> >> > On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator <
> revi...@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.
lldb-commits mailing list