jasonmolenda added a comment. Regarding the part of the patch where eh_frame is used unconditionally on Linux systems, I'm hesitant to make a change like that (beyond the notes I mentioned earlier about how I'd do it in FuncUnwinders instead of down in RegisterContextLLDB). Modern gcc's put out eh_frame with prologue and epilogue descriptions on x86_64 - but there's no guarantee that eh_frame we see on a linux or bsd system will come from a modern gcc. For instance, clang (last I checked) does not emit epilogue information in the eh_frame (as did gcc until a few years ago). gdb does pretty well relying exclusively on eh_frame, but the design of the lldb unwinder was to do better than gdb, by using multiple sources of unwind information.
Of all the unwind info sources, eh_frame is the most frustrating, IMO. It *can* be everything a debugger could ever need -- but it isn't guaranteed to be that. It's only guaranteed to be enough for exception handling, which is a very different set of requirements from what a debugger needs. And there's no reliable way for a debugger to tell how descriptive an eh_frame entry is. http://reviews.llvm.org/D21221 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
