Add as little code as possible to allow compiling lldb on LoongArch.
Actual functionality will be implemented later.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/source/Plugins/Process/Linux/CMakeLists.txt | ||
---|---|---|
11 | Had better use git diff -U999999 to generate the patch so that we can get more context. |
Use git diff -U999999 to generate the patch so that we can get more context suggested by Weining.
Hi, I've edited the summary and patch title for you. It's generally not necessary to add that much "politeness" when most of it is obvious from context (e.g. the fact that you're new face here, that there's obviously no LoongArch support in LLDB, and most of the methods being stubs). It didn't help that much of the text was in Chinglish either.
As for the changes, they look reasonable to me, but as I haven't tested it out myself yet (and unable to, due to it being stub-only), I'll not give the approval myself this time. Thanks for your contribution and welcome!
Always good to see another architecture in lldb.
A few points up front.
Changes like this are fine and we can review them, but can only be landed once we see that they'll be built on. So please stack changes so that we can see what is upcoming. https://llvm.org/docs/Phabricator.html#creating-a-patch-series
Do you have a plan to test this configuration? I don't see any public buildbots for Loongson (please correct me if I am wrong) but that is not a requirement as long as you have some testing plan (RISCV doesn't have a public bot, as one example).
Do you have community members who can review these changes for architectural correctness? Speaking just for myself I am happy to review bits of lldb machinery but when it comes to architecture details I am not, and will not, be an expert in Loongson.
I'm ok accepting patches without a second reviewer, but I advise for your own benefit to try to find someone who already knows the details of Loongson.
OK, thank you.
lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_loongarch64.cpp | ||
---|---|---|
44 | It is just a stub function here to build successfully, actually it should return k_num_gpr_registers lldb/source/Plugins/Process/Utility/lldb-loongarch-register-enums.h |
Hi @DavidSpickett, thanks for your advice. I (as the LoongArch backend code owner) can review these changes for architectural correctness. And I think other LoongArch community members (non Loongson employees) also can take it. Especially @xen0n and @xry111 who are quite familar with LoongArch.
What's more, AFAIK, @seehearfeel (yangtiezhu@loongson.cn) is the LoongArch port maintainer of gdb.
Regarding the public buildbot, I'm trying to set it up and maybe we can see it in one or two weeks.
lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.h | ||
---|---|---|
10 | Seems #if __loongarch_grlen == 64 is enough? But I'm fine with both. | |
25 | Pls limit the columns count to 80 which can be done by clang-format. See: https://llvm.org/docs/Contributing.html#how-to-submit-a-patch |
lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_loongarch64.h | ||
---|---|---|
27 | Now, GPRegSet and FPRegSet are not used, |
What's more, AFAIK, @seehearfeel (yangtiezhu@loongson.cn) is the LoongArch port maintainer of gdb.
Regarding the public buildbot, I'm trying to set it up and maybe we can see it in one or two weeks.
Great!
Build is OK on my local LoongArch machine with 299 failed tests and 2 timed out tests. Just as the summary says, I think this is expected.
Remove GPRegSet and FPRegSet definitions which are not used in this commit.
Use git clang-format to format the patch properly.
This LGTM from the lldb side.
Feel free to upload a series of patches in future if you want. You don't have to do one at a time, just update the whole stack as needed. Plus it gives the reviewers some context of what the changes are working towards.
Do you have commit access? If not it's fine to wait until you have (https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access), or someone else can land on your behalf. Just provide a name and email address you'd like to be on the commit.
lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_loongarch64.h | ||
---|---|---|
27 | Why is this structure and below FPR defined like this? Do you intent to keep the layout same as some structures of Linux? If yes, is it necessary? |
lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_loongarch64.h | ||
---|---|---|
27 | It seems necessary because lldb invokes ptrace system call which directly stores into the pointer returned by GetGPRBuffer. |
OK, thank you.
Feel free to upload a series of patches in future if you want. You don't have to do one at a time, just update the whole stack as needed. Plus it gives the reviewers some context of what the changes are working towards.
I am a newcomer, here are some of my thoughts:
(1) Add the minimal changes to fix the build errors.
(2) Submit other more patches step by step to make
the basic command "run", "breakpoint", "next" ...
can be used to debug, single patch or patch series.
(3) Add more code to make more commands work well.
Do you have commit access? If not it's fine to wait until you have (https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access), or someone else can land on your behalf. Just provide a name and email address you'd like to be on the commit.
I have no commit access now, @SixWeining luweining@loongson.cn
can land on my behalf, here are my name and email:
Tiezhu Yang
yangtiezhu@loongson.cn
LGTM for LoongArch related changes.
lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_loongarch64.h | ||
---|---|---|
27 | Make sense. Thanks. |
I am a newcomer, here are some of my thoughts:
(1) Add the minimal changes to fix the build errors.
(2) Submit other more patches step by step to make
the basic command "run", "breakpoint", "next" ...
can be used to debug, single patch or patch series.
(3) Add more code to make more commands work well.
Sounds like a good approach to me.
I believe the riscv effort focused on parts of the test suite in turn, sounds like you'll do the same.
can land on my behalf
Will do.
Regarding the public buildbot, I'm trying to set it up and maybe we can see it in one or two weeks.
FYI. D138672 is the review for adding LoongArch buildbot.
Had better use git diff -U999999 to generate the patch so that we can get more context.
See: https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface