[Lldb-commits] [PATCH] D62732: [RISCV] Add SystemV ABI

[Jason Molenda via Phabricator via lldb-commits]

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