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> > wrote: > >> > >> > >> > 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. > > J
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
