Differential D128250
[LLDB][RISCV]Add initial support for lldb-server. Authored by Emmmer on Jun 21 2022, 1:19 AM.
Details
I added some initial support for lldb-server on riscv64 platform, now it can be built on riscv64. error: 'A' packet returned an error: -1 I tried to fix this error with gdb, but the debugging process was too slow, so I'm sorry for not being able to provide a test patch for verification of my commit.
Diff Detail Event TimelineComment Actions I'll give this a more thorough read later just one comment for now. In the meantime, what's your plan for testing this config going forward? This patch would be fine as the first of a series but I'd like to see the follow ups that make it usable. Will there be a build bot? You could at least enable building lldb on an existing riscv bot, while you iron out all the inevitable test suite issues.
Comment Actions To use gdbserver by lldb requires the participation of lldb-server, so my current plan is to allow lldb to co-op with gdbserver, then let lldb be able to use lldb-server, pass the unit tests, and finally add riscv32 support. Comment Actions Overall this looks fine. Without the ability to test it I don't think we would accept it yet, so I didn't look into the details too much.
Sounds good. If those lldb changes can be tested by existing bots then they can go in first. For anything else it's probably better to build a tree of your changes and when you've got something that ends in a testable lldb-server then put them into review. I appreciate it's difficult to test a lot of the enabling code e.g. the breakpoint code in this change. That'll be exercised by the test suite in general once more things are working. So it would be fine to say here is a series that ends in an lldb/lldb-server that can run a large amount of existing tests. If you find anything non-riscv specific e.g. some gdb protocol difference that can go into review whenever. Anything to improve lldb-gdb compatibility is welcome.
I'm not familiar with this infrastructure. In a future where your changes are in llvm main will developers be notified when they break the riscv lldb build?
Comment Actions
Oh and if you want help with this please ask on discord/discourse. This stuff is a bit tedious with so many exchanges on first connection.
Comment Actions This patch change:
I would like to add support for GPR first, after making sure they work well, FPU regs are a simple copy-paste.
Thanks for your suggestion, I split them out.
At first, I referenced the AArch64 code to add riscv64 support because their arch is similar, but I overlooked that riscv64 doesn't have a Debug reg yet, so it was a mistake on my part. Comment Actions I try to build lldb with the patch, but fail: The environment： cat /proc/cpuinfo processor : 0 hart : 2 isa : rv64imafdc mmu : sv39 uarch : sifive,u74-mc llvm commit: d1b098fc Command: cmake -DLLVM_TARGETS_TO_BUILD="RISCV" -DLLVM_ENABLE_PROJECTS="lldb" -DCMAKE_BUILD_TYPE="Release" -G Ninja ../llvm Error: CMake Error at /home/liaochunyu/llvm-project/lldb/cmake/modules/LLDBConfig.cmake:289 (message): Expected directory for clang-resource headers not found: Call Stack (most recent call first): /home/liaochunyu/llvm-project/lldb/CMakeLists.txt:28 (include) -- Configuring incomplete, errors occurred! Comment Actions The most convenient way to handle clang dependencies is adding clang to LLVM_ENABLE_PROJECTS -DLLVM_ENABLE_PROJECTS="lldb;clang" Comment Actions FWIW I do get the same error in a clean directory without this patch applied: -- LLDB version: 15.0.0git CMake Error at /home/david.spickett/llvm-project/lldb/cmake/modules/LLDBConfig.cmake:289 (message): Expected directory for clang-resource headers not found: Call Stack (most recent call first): /home/david.spickett/llvm-project/lldb/CMakeLists.txt:28 (include) There's probably a better way to tell the user what to do but that's how it works at the moment. The "standard" set of projects to enable is lld, clang and lldb if you want to build and test lldb. Comment Actions We do have a separate test suite just for lldb-server, so you might be able to use that to gauge your progress without worrying about the lldb side too much. I wouldn't say that the presence of a buildbot is an absolute requirement to get this off the ground, but I would strongly recommend setting up one, even if it's just building for now. We don't e.g. have a bot for SystemZ, and the overall effect of that is that nobody knows whether SystemZ debugging actually works.
Comment Actions
I currently don't quite understand how to configure the build bot, and how to set the test configuration, I went through this article but didn't find useful information for me, could someone help me. Comment Actions
It is a virtual function so I decided not to call it from the constructor. Comment Actions
Start with https://llvm.org/docs/HowToAddABuilder.html instead. Though it may be better to propose adding the lldb-server build to an existing riscv buildbot, which would be a case of reaching out to the owner and/or proposing a change on https://github.com/llvm/llvm-zorg to add the build target to the bot's config. Comment Actions This patch change:
Now lldb can debug with simple executables on qemu-system-riscv64 and be able to attach to a gdbserver. TODO: some unittest failed bash [ RUN ] TestBase.LaunchModePreservesEnvironment /home/emmmer/git/llvm-project/lldb/unittests/tools/lldb-server/tests/LLGSTest.cpp:29: Failure Value of: llvm::detail::TakeExpected(ClientOr) Expected: succeeded Actual: failed (Unable to parse qRegisterInfo: generic) [ FAILED ] TestBase.LaunchModePreservesEnvironment (662 ms) [ RUN ] TestBase.vAttachRichError Connection established. Launched '/home/emmmer/git/llvm-project/build-cross/tools/lldb/unittests/tools/lldb-server/./environment_check' as process 1553... lldb-server-local_build Connection established. Launched '/home/emmmer/git/llvm-project/build-cross/tools/lldb/unittests/tools/lldb-server/./environment_check' as process 1556... lldb-server-local_build /home/emmmer/git/llvm-project/lldb/unittests/tools/lldb-server/tests/LLGSTest.cpp:60: Failure Value of: llvm::detail::TakeExpected(ClientOr) Expected: succeeded Actual: failed (Unable to parse qRegisterInfo: generic) [ FAILED ] TestBase.vAttachRichError (364 ms) In riscv, the user-mode process cannot directly take the pc register but must obtain the pc state through auipc, while the pc register is required to exist in the test, so it failed. bash
[ RUN ] DumpDataExtractorTest.Formats
/home/emmmer/git/llvm-project/lldb/unittests/Core/DumpDataExtractorTest.cpp:90: Failure
Expected equality of these values:
expected
Which is: "{-nan -nan nan nan}"
result.GetString()
Which is: "{nan nan nan nan}"
[ FAILED ] DumpDataExtractorTest.Formats (25 ms)The reason is currently unknown, and further verification is required About buildbot: Unfortunately, as an individual developer, I may not have the ability to maintain a 7*24-hour compile server or even a cluster, but I will do my best to provide some test reports. Comment Actions This commit updates:
The NaN problem has been solved by D129750 At this point, we can pass all LLDBUnitTest. It may be challenging to review and merge at one time for such a large patch. I would like to ask if it‘s necessary to split this patch and merge them in turn.
Comment Actions Hello: I implemented the diff into my local llvm project and cross-compiled the project using in-tree build with enable projects as: The project can be compiled using the "Release" mode. The lldb-server can be initiated and connected to the host machine from the qemu environment. It can ran the riscv binary using process continue / thread continue, but the compiled lldb-server cannot get any thread information and cannot perform thread step-in functionality. Then I performed the Debug mode to build the project. Error occurred so the build command cannot be finished. The error shows like: [3759/4081] Linking CXX shared library lib/libclang-cpp.so.15git Can your lldb-server work properly on the riscv qemu environment? My question might be, what is the proper recipe for cross-building the lldb-server? Or, should the diff be changed to enable getting the thread instruction info of the lldb-server? Thank you very much! Comment Actions One more detail about the ThreadInfo: This is the strace of my lldb-server runing on the qemu: recvfrom(9, "$jThreadsInfo#c1", 8192, 0, NULL, NULL) = 16 Comment Actions Hello: Thank you so much for sharing the patch files. One thing I am still curious is what the ABISysv file you are using. Would you mind also sharing the remaining patches added for the lldb-server support? Comment Actions
I didn't add any ABISysV code before uploading this patch, and now I'm struggling with the breakpoints not hit problem, and it may be related to ABISysV. Comment Actions Cool! There is one thread talking about the RISCV ABI support: https://reviews.llvm.org/D62732. I tried that ABI in the RISCV file but it seems like the same issue happened as yours, the breakpoint cannot be stopped, and the lldb-server cannot show the reasonable stack frame pointer address. So I think the ABI support should be modified. Comment Actions
The ABI support you mentioned does not relate to breakpoint mechanism in lldb-server (but it may be required by other features). lldb-server failed to add breakpoints due to the lack of trap code implementation in NativeProcessProtocol::EnableSoftwareBreakpoint. You can checkout the new revision in D130342 which successfully set the breakpoint on a statically linked executable. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Please use the standard llvm header with licence info and stuff.