jasonmolenda added a comment. In D62732#3680154 <https://reviews.llvm.org/D62732#3680154>, @tzb99 wrote:
> In D62732#2790160 <https://reviews.llvm.org/D62732#2790160>, @sven wrote: > >> >> But the unwind can not work on my machine, the issue is similar to which >> @jade reported >> >> (lldb) bt >> * thread #1, stop reason = breakpoint 1.1 >> * frame #0: 0x0000000080000022 kern`fn3 at start.c:7:8 >> >> Can you reproduce this problem? Or please show me how you fix the issue, >> thanks very much. > > Hi: I encountered the similar issue with the frame address showing all 1s. I > tried to install libxml2-dev and wanted to recompile lldb. How did you > recompile lldb? Do you cross compile or compile inside the qemu environment? > If you do cross-compile, would you mind show the arguments of cmake? Thank > you very much! > > PS: I use cmake arguments and followed the instructions on the lldb website > to do the LLVM in-tree build. I will encounter errors if I set enable xml2 to > be ON: > > /usr/include/libxml2/libxml/encoding.h:31:10: fatal error: unicode/ucnv.h: No > such file or directory > > 31 | #include <unicode/ucnv.h> > | ^~~~~~~~~~~~~~~~ > > compilation terminated. ================ Comment at: lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp:142 + // The previous frames pc is stored in ra. + row->SetRegisterLocationToRegister(pc_reg_num, ra_reg_num, true); + ---------------- jrtc27 wrote: > And SP is just.. the same? Surely the default unwind plan is to load SP and > RA via FP? You won't get very far with this. Following up to @jrtc27 's comment here because I saw people saying they were getting only one stack frame in their backtraces. I don't know this ISA/ABI, but this DefaultUnwindPlan probably only works correctly on the first instruction of a function. Normally the DefaultUnwindPlan should be expressed in terms of how to find the caller stack frame from the middle of the function body -- once the prologue has executed, and you're using a frame pointer register to track your stack frame, most likely. For real quality unwinds, we can use DWARF debug_frame or eh_frame, and/or we have an instruction emulation engine that tracks register spills and stack frame setup/teardown and creates an unwind plan at every instruction point using that. But the RISC-V back-end would need to be written for that; a bit of work. For a starting point, unwinding from the middle of the function is the right thing to do by default. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62732/new/ https://reviews.llvm.org/D62732 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
