Looks like we crossed paths and have been thinking about the same things.
I like that treating 1-3 separately raises the possibility of testing them
in an architecture agnostic way.
As for #4, this might be a moonshot, but what about qEMU or something?
On Thu Feb 19 2015 at 3:18:53 PM Jason Molenda <jmole...@apple.com> wrote:
> 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
