android-riscv64
android-riscv64 copied to clipboard
google
lldb: does it work sufficiently well for Studio?
at some point we should make sure that lldb works well enough for all the functionality exposed by Studio to work correctly. (if nothing else, "does it pass the manual QA tests?".)
lldb-server will be built once https://android-review.googlesource.com/c/toolchain/llvm_android/+/2617939 is merged. If you follow the instructions from https://android.googlesource.com/toolchain/llvm_android/+/master/README.md and cherry-pick that commit, you will get out/lib/lldb-server-riscv64-ndk-cxx/bin/lldb-server, which is working for me with lldbclient.py from AOSP.
Thanks for verifying it works. https://android-review.googlesource.com/c/toolchain/llvm_android/+/2617939 was just to see if lldb-server builds but glad to know it is also functional. If you find any quirks related to risc-v in the debugging flow, do keep us in the loop.
LLDB on RISC-V has the issue that stack traces only show the current and previous frame. We need https://reviews.llvm.org/D62732, https://reviews.llvm.org/D159101, or equivalent to get full stack traces.
Using this version ttps://ci.android.com/builds/branches/aosp-master-ndk/grid?legacy=1 for verification, neither lldb nor profile works.
lldb server not found:
Please help continue to take a look
D159101 has landed https://github.com/llvm/llvm-project/commit/847de9c332775d1841fec9fea5cb5c41592a4c8f. Is D62732 still needed @SiFiveHolland?
@appujee --- is that patch in the latest toolchain update?
@DanAlbert --- i'm assuming that even if it's in the platform, it's not in any NDK (other than canaries) yet?
@appujee --- is that patch in the latest toolchain update?
Yes it is: https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/refs/heads/main/clang-r510928/clang_source_info.md has [RISC-V] Add RISC-V ABI plugin
@DanAlbert --- i'm assuming that even if it's in the platform, it's not in any NDK (other than canaries) yet?
It's not in the NDK canaries yet. They're on the older clang version. @DanAlbert it'd be worth updating the NDK master branch to clang-r510928 to find any breakages (even though we'll have a newer toolchain for r27).
As of August 27, 2024, the status of LLDB / llldb-server (taken from clang-r536225) in Android Studio is as follows:
| Operation | Works? | Notes |
|---|---|---|
| Step over | No | |
| Step into / Step out | No | error: Could not create return address breakpoint. |
| Stack trace | No | |
| Hit Breakpoint / Continue | Yes | |
| List Threads | Yes | |
| Show locals, parameters | Yes | |
| Dynamic loader breakpoint | No | This means we can only test with attach-to-existing-process |
| Disassemble | No | error: Failed to disassemble memory at 0x2d2952c018 |
Dynamic loader breakpoint
any idea what the problem could be there? there shouldn't be anything different on the dynamic linker side than any other architecture ... does lldb have some Android-specific arch-specific hacks on its side that we need to duplicate? (or does riscv64 work differently here in some way, and we do need to do dynamic linker work?)
When I attach with LLDB and execute through a dlopen() call, I get a signal SIGILL: illegal opcode error. It could be just that, or there can be more problems further. Since disassemble doesn't work, I couldn't dig any deeper to understand where in the dynamic loader this happens.
does lldb have some Android-specific arch-specific hacks on its side that we need to duplicate? (or does riscv64 work differently here in some way, and we do need to do dynamic linker work?)
There is nothing Android-specific that I know of.