OK, I see what you're thinking of. I was looking at this from a dynamic point of view with an actually running process. We need a live process for most of the unwinder stuff to work correctly -- you don't have any information about registers until you can get a RegisterContext from a Thread. That means you can only run the tests on a matching architecture system. (e.g. see the ctor in this patch where it gets a RegisterContext to look up registers by name).
We'd need also need to add a feature like "show me the unwind info for this block of bytes". What we really need is an SB API for representing unwind information and an API to get the unwind information for a block of bytes. Otherwise our test file has to do something like parse the output of "image show-unwind" in some form. Given that these unit tests could only be run on the mips64 system itself, we don't get anything from adding all these facilities - we could do the hand-written assembly approach and test behaviors with the higher level lldb cmds. REPOSITORY rL LLVM http://reviews.llvm.org/D7696 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ lldb-commits mailing list lldb-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
