labath added a comment. In D61732#1496575 <https://reviews.llvm.org/D61732#1496575>, @clayborg wrote:
> Looks good except the inline comment about all the unwind plans we have now. > Would love to simplify this so that EH frame, compact unwind, ARM unwind, > breakpad unwind all come from the symbol file or object files. Also be nice > to have a register resolver that works without having a process so we can > dump unwind info without needing a process. I was also considering that (making unwind plan providers more pluggable), but I gave up after a day or two of experimenting. As I recall, the main problem was that there are places in code that go straight for a specific unwind plan instead of just asking for a "(non)call site unwind plan". Some of those use cases are relatively reasonable: e.g. one can ask for an eh_frame unwind plan even if he does know the exact symbol and it's boundaries where he's stopped at, but that is definitely not the case for the "instruction emulation" plan. It wasn't clear to me how to reconcile these requirements, so I just went with the approach that preserves status quo. Given that most of these unwind plans are not tied to a specific object/symbol file format (I didn't realize that compact unwind is specific to mach-o), encapsulating them inside a plugin did not seem to be that important. The thing that could help with the readability here is to avoid having a separate shared_ptr for the plan, and a bool flag for whether we attempted to create the plan. Encapsulating that into a single entity would go a long way towards making this class more readable, but it would also increase the size of this class (i'm not sure how much we care about that). There are also ways to do that without increasing the size (or even with decreasing it), but they would all be more or less magical, which I wasn't sure whether is worth it. I definitely plan to look into making unwind plan computation possible without a running process but that will require us to get a different source of truth for the register eh/dwarf numbers (right now we get those from the remote stub), which is not going to be an easy task. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61732/new/ https://reviews.llvm.org/D61732 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
