This is an archive of the discontinued LLVM Phabricator instance.

[RISCV][LLDB] Add initial SysV ABI support
Needs ReviewPublic

Authored by kasper81 on Aug 23 2022, 3:35 PM.

Details

Summary

Supersedes https://reviews.llvm.org/D62732, since author is not working on it anymore (https://reviews.llvm.org/D62732?vs=on&id=341471#3561717).

This is to get the basic stuff working with DefaultUnwindPlan. We can incrementally add more plans in the future and make the implementation more robust. |

Diff Detail

Event Timeline

kasper81 created this revision.Aug 23 2022, 3:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 23 2022, 3:35 PM
kasper81 requested review of this revision.Aug 23 2022, 3:35 PM

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.

Currently, lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp only handles a few jump instructions, we can refine it further if needed.

lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
39

This enum can be included from lldb/source/Utility/RISCV_DWARF_Registers.h

kasper81 added a comment.EditedAug 24 2022, 5:35 AM

@jasonmolenda the problem with original review is that we were waiting for the wholesale support for 3.5 years, and it rendered into an impossible task for the author. I don't want to make this one "all or none" kind of a deal as well. This patch is neither bringing 100% lldb support nor regressing. It is an incremental step forward to unblock a few more scenarios to initialize SysV ABI.

After this, we probably first need RISCV support in lldb/source/Plugins/Architecture which will then be used in Core to unlock some other scenarios and then we can further enrich these features in small and fast iterations. @Emmmer has a better understanding of what is left.

kasper81 updated this revision to Diff 455176.Aug 24 2022, 6:04 AM
This comment was removed by kasper81.
kasper81 updated this revision to Diff 455177.Aug 24 2022, 6:10 AM
kasper81 marked an inline comment as done.
kasper81 added inline comments.Aug 24 2022, 10:28 AM
lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
39

Thanks, I have reused that header.

@jasonmolenda the problem with original review is that we were waiting for the wholesale support for 3.5 years, and it rendered into an impossible task for the author. I don't want to make this one "all or none" kind of a deal as well. This patch is neither bringing 100% lldb support nor regressing. It is an incremental step forward to unblock a few more scenarios to initialize SysV ABI.

Perfectly reasonable. I don't have any problems with this patch, but you might want to add a little FIXME comment in CreateDefaultUnwindPlan noting that it should create a frame-pointer-based unwind plan a la any of the ARM ABI plugins, that this unwind plan is only correct on the first instruction or a leaf function that does not set up a stack frame. I'd also duplicate that method under the name CreateFunctionEntryUnwindPlan() because I believe this is a correct implementation of that ABI method.

kasper81 updated this revision to Diff 455371.Aug 24 2022, 2:15 PM

Added a FIXME comment in CreateDefaultUnwindPlan, based on advice from @jasonmolenda.

@jasonmolenda. @Emmmer, I've addressed your review feedback. Could you please take another look?

Emmmer added a subscriber: labath.Aug 26 2022, 9:52 AM

I have to say sorry after reading your update but not giving you feedback.
I pulled your patch and found it does not compile, and I have fixed them for you :)

ABI plugins are one of the hardest things to test in lldb, particularly without actual hardware. That's why we've let them be added in the past without any accompanying tests. The situation is not ideal though, because we've accumulated various ABI plugins which are hard to change without breaking (or even to know if they work) because they only work with third-party (possibly proprietary) stubs.

I have tried to work on ABISys_V plugins, but I think it is difficult because I am not able to check whether ABIPlugin works well.
It will be nice if we have some tests.

lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.cpp
38–40

modify target name.

158–163

Using .isRISCV() instead of
arch.GetTriple().getArch() == llvm::Triple::riscv32 || arch.GetTriple().getArch() == llvm::Triple::riscv64
and remove braces from if statment

176–185

We can remove this since we defined it in ABISysV_riscv.h

lldb/source/Plugins/ABI/RISCV/ABISysV_riscv.h
95–99

GetPluginVersion() is unused.

lldb/source/Plugins/ABI/RISCV/CMakeLists.txt
2

modify target name

kasper81 updated this revision to Diff 455977.Aug 26 2022, 11:46 AM
kasper81 updated this revision to Diff 455982.Aug 26 2022, 11:50 AM
kasper81 marked 3 inline comments as done.
kasper81 marked 2 inline comments as done.

Addressed review feedback.

@Emmmer, agreed that automated tests for ABI plugins would be a nice thing to have at some point in the future, but it is out of the scope of this initial bring up for RISCV, as tests are missing for all architectures. Also we need Plugins/Architectureport for RISCV to get the exotic use cases working. So best way is to make individual short patches with fast iterations rather than stuck on one thing for years.

@jasonmolenda, @Emmmer, any other feedback, or good to merge? i will work on Plugins/Architecture/RISCV, unless someone else beat me to it. :)

kasper81 edited reviewers, added: jasonmolenda; removed: tzb99.Sep 20 2022, 2:42 AM
jasonmolenda accepted this revision.Sep 20 2022, 4:02 PM

@jasonmolenda, @Emmmer, any other feedback, or good to merge? i will work on Plugins/Architecture/RISCV, unless someone else beat me to it. :)

FWIW looks good to me, @Emmmer 's feedback is more relevant than mine here but IMO any shortcomings in the current patch can be iterated on later; getting this landed would be good.

This revision is now accepted and ready to land.Sep 20 2022, 4:02 PM
kasper81 requested review of this revision.Oct 24 2022, 4:56 AM

@MaskRay could you please take a look?

@labath, if there is anything needed by me, please let me know. i'm new to phabricator patch system. :)

evandro removed a subscriber: evandro.Jun 5 2023, 3:38 PM

@kasper81, I just tried this patch with lastest repo in github and can bulid patched lldb. But when I try to remote debug with riscv qemu, it still get all 1s frame. Could you please see what I'm doing wrong?