I don't have any objections to this test idea. Trying to encapsulate tricky unwind scenarios in an arch-independent manner is very hard. IMO the only way to do this is hand-written platform-specific assembly or platform-specific corefiles that capture a problematic program state.
Realistically, the unwinder doesn't fail on C/C++ compiled code -- I mean, if it does, there are some big problems that we need to address. The tricky stuff is always dealing with hand-written assembly code, or trying to backtrace through an asynchronous signal handler like sigtramp()/sigtrap(), or backtracing from address 0, or backtracing as we step through an assembly stub routine that jumps to another real destination function, or backtracing through jitted code that has no associated Module at all in lldb. Sure, turn on -fomit-frame-pointer and see if lldb follows the eh_frame correctly as you stepi through a function (prologues and epilogues are always the most likely to get you the wrong caller func) but I don't think it'll be a rich source for regression detection. I don't mean to discourage this, please do this. I've been thinking about the problem of testing unwinds for a while now, and I'm not happy with any of the obvious approaches. And it's such a critical component of the debugger, and so easy to break, that we really do need to work on this more. http://reviews.llvm.org/D10454 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
