<div dir="ltr">Yesterday a <a href="http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20150216/015996.html">change</a> went up for review to add support for mips64 in the unwinder.  In the review, I proposed adding some tests.  There was some discussion in the thread, but I don't want to pollute someone's review thread with a long disucssion, and I thought maybe more people would be interested.  So I'm moving it over here.<div><br></div><div>For some context, I proposed the idea of testing this type of thing via unit tests.  I certainly thing that do a full live-system debugging test would be useful for this type of thing, but I think this is a great example of where a unit test would provide a lot of value.  For starters, the full scale tests are very heavyweight.  There's a lot of setup involved, they're slow, they're platform specific.</div><div><br></div><div>I think for tests like this we can write them as UnitTests in a way that they're faster, lighter weight, more targeted, <b>and</b> platform independent.  One of the issues brought up in the commits thread linked above is that the test would only be able to run on mips hardware.  I disagree.  The test could come with a file containing hand-written assembly.  We can use the LLVM assembler to target mips, which will generate mips bytecode no matter which platform you're on.  Then we can just feed the bytes to the unwinder.  </div><div><br></div><div>Of course, you need a RegisterContext.  We would probably have to make some changes to the unwinder so that the RegisterContext could be abstracted out.  This way, a test could provide its own mock register context and target memory reader.  </div><div><br></div><div>You still need a full-scale integration test to confirm that unwinding actually works in context.  But I think we should consider unit tests for things like this.  It's difficult to write unit tests right now because the code in many places is not well testable (for example, not being able to abstract the registercontext so that a test could provide its own).  </div><div><span style="font-size:13.1999998092651px"><br></span></div><div><span style="font-size:13.1999998092651px">But I want to just toss this out there and see how much pushback I get.  If it's something people are interested in, then it's something we could work towards gradually.  I think we can all agree that checking in code with 0 tests sucks, so hopefully we can work towards something that gets us into a better state.  Getting more full-scale public API tests is one angle we can approach it from.  But I think unit tests would be some nice additional ammo we could throw at the problem, if we work towards better abstractions and more testable code.</span></div><div><span style="font-size:13.1999998092651px"><br></span></div><div><span style="font-size:13.1999998092651px">Thoughts?</span></div></div>