<p dir="ltr">Regardless of this patch, is instruction emulation going to yield the best results for all architectures?<br>
</p>
<div class="gmail_quote">On Feb 21, 2015 2:03 AM, "Jason Molenda" <<a href="mailto:jmolenda@apple.com">jmolenda@apple.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't want to necessarily disagree with Greg but his suggestion about implementing an instruction emulation approach is a pretty big change to this patch.  There are two approaches to creating an unwind plan based on an instruction stream:  Hard-code knowledge about a small set of instructions that appear in function epilogues/prologues and use a disassembler to step over the unknown instructions, or have an instruction emulator that knows the behavior of them (well enough) so it can model the relevant instructions.<br>
<br>
For arm & arm64, lldb uses instruction emulation.  This was aided by the ARM instruction xml files which allow for much of the emulation code to be generated.<br>
<br>
The emulation approach allows for great flexibility, but it is (obviously) a lot more work.  The emulation approach can win when unusual function prologue instructions appear -- with the hard-coded instruction analyzer you need to know all of the different instructions that the compiler or hand-written assembly may use to manipulate the stack pointer, frame pointer, the caller's instruction and any saved registers.<br>
<br>
I don't think we should reject this patch in favor of writing this in the emulation style - that's likely to be a big ask.<br>
<br>
<br>
REPOSITORY<br>
  rL LLVM<br>
<br>
<a href="http://reviews.llvm.org/D7696" target="_blank">http://reviews.llvm.org/D7696</a><br>
<br>
EMAIL PREFERENCES<br>
  <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
<br>
<br>
</blockquote></div>