jasonmolenda added a comment. I think this DefaultUnwindPlan has the same problem that the previous patch did -- this looks like the unwind state on function entry. There is an `ABI::CreateFunctionEntryUnwindPlan()` for the unwind state on the first instruction of a function, but the idea of DefaultUnwindPlan is for backtracing through jitted code, once the stack frame has been set up -- usually the stack pointer is copied into the frame pointer, maybe with a decrement, and the original frame pointer & return address registers are spilled to stack memory. Any of the arm ABI plugins are good examples of this kind of architecture.
Beyond DefaultUnwindPlan, usually the next place we get unwind information is from eh_frame, and lldb uses an instruction emulation system as a source of unwind information. A static scan of all the instructions in the function, tracking branches and register spills, stack pointer/frame pointer manipulations, and creates an UnwindPlan from those. That's a pretty big chunk of work though. although lol I missed that this has already been started, v. lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D132510/new/ https://reviews.llvm.org/D132510 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
