<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br>
><br>
> zturner added a comment.<br>
><br>
> In <a href="https://reviews.llvm.org/D43048#1005513" rel="noreferrer" target="_blank">https://reviews.llvm.org/D43048#1005513</a>, @jasonmolenda wrote:<br>
><br>
> 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.<br>
<br>
<br>
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.<br></blockquote><div><br></div><div>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).</div></div></div>