labath added a comment. Yes it sounds like the situation is very much similar here as it is in dwarf land -- the compilers there also don't tend to emit unwind info for prologues and epilogues.
The thing to realize about the instruction emulation is that it is always going to be a best effort enterprise. We can try to pattern match the sequences generated by the compilers, but it's always going to be playing catch up, and prone to false positives. That's why it's important to use the debug info provided by the compiler, as it is in a much better position to generate the unwind info. Even the emulator itself has two modes of operation: in the first one it synthesizes the unwind info out-of-the-blue. In the second one it takes the existing unwind info and "augments" it with additional rows. Obviously, the second one is much more easier to implement and reliable. The conversion of the FPO programs into DWARF does not sound like a particularly fun enterprise, though I'm not sure if that's the only way to do this kind of thing. In any case, it sounds like the process should be easily unit-testable. As for the saved registers, won't the compiler's unwind info contain that information? I would expect that is necessary for exception unwinding.. tl;dr; I am not against improving the instruction emulator. I just think it's not the most important priority right now. Getting the compiler-generated info working puts the emulator out of the critical path, and leaves it just responsible for the less frequent cases when someone is stopped in the middle of the prologue, or needs to access a variable that resides in a spilled register. But if you want to work on the emulator first, then go ahead.. https://reviews.llvm.org/D53086 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
