Thanks for raising this outside the scope of that one patch review.
There are different things we may want to test related to the Unwinder
subsystem:
1. Testing of assembly instruction profile generated unwind instructions
(looking at the assembly instructions, spotting the insns relevant to
unwind, emitting unwind instructions for them.)
2. Testing of eh_frame parsing & the generated unwind instructions
3. Testing of compact_unwind {Darwin specific format} parsing & the generated
unwind instructions. This one is arch specific so testing i386/x86_64/arm64
are all valuable.
4. Unwind behavior correctness. Do we pick the correct unwind plan (eh_frame?
compact unwind? assembly language profiling? Augmented eh_frame? The ABI
arch default unwind plan? Do we backtrace correctly if the program jumps to 0?
The answers may differ depending on whether we're looking at frame 0 or frame
1+) Does the unwinder follow the unwind plan instructions correctly to
retrieve saved register values on the stack?
For 1-3, static analysis -- without a live running process on the correct
architecture -- is possible and is a worthwhile goal. The unwind plan CREATORS
will need some help to work without a live RegisterContext to get register
information. (this dependency for this layer is almost exclusively of the
form, "I know that rbx is register 2 in the machine's register numbering
scheme, what is it in lldb's native register numbering scheme?")
Whether it's a blob of bytes or a .s file that we use clang to build for the
appropriate architecture, whatever, if the clang that we build has those
targets built in reliably we can do it at testsuite run time.
There's the other side of this that we'll need to come up with an SBUnwindPlan
type class that can be queried for all of the unwind details for a function.
For #4, we'll need live processes and/or core files - I don't see any way
around that.
> On Feb 19, 2015, at 10:33 AM, Zachary Turner <ztur...@google.com> wrote:
>
> I think for tests like this we can write them as UnitTests in a way that
> they're faster, lighter weight, more targeted, and 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.
>
> 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.
>
> 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).
>
> 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.
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
