> 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.

lldb-commits mailing list

Reply via email to