Description
LLDB has a bug which prevents it from reading the last entry in an APK. This bug is know and fixed in the LLVM project. The fix is trivial, please cherry-pick it for NDK 30.
The result of this bug is that, when debugging native code in an APK with the lldb-server provided in the NDK, if the code is located in a shared library (.so) which is stored as the last entry in the APK, LLDB is not able to load that binary image, and the corresponding code cannot be debugged (no breakpoints, no link to the source code, ...).
The bug existed in NDK 27r already.
See:
llvm/llvm-project#173966
llvm/llvm-project@5ed875a
Upstream bug
llvm/llvm-project#173966
Commit to cherry-pick
5ed875a06cb0a6d543f719ad72df2a1660e42cb9
I am using a supported NDK
Affected versions
r27 (probably all, including 30-beta-1)
Host OS
Mac
Host OS version
macOS 26.4.1
Affected ABIs
arm64-v8a
Description
LLDB has a bug which prevents it from reading the last entry in an APK. This bug is know and fixed in the LLVM project. The fix is trivial, please cherry-pick it for NDK 30.
The result of this bug is that, when debugging native code in an APK with the lldb-server provided in the NDK, if the code is located in a shared library (.so) which is stored as the last entry in the APK, LLDB is not able to load that binary image, and the corresponding code cannot be debugged (no breakpoints, no link to the source code, ...).
The bug existed in NDK 27r already.
See:
llvm/llvm-project#173966
llvm/llvm-project@5ed875a
Upstream bug
llvm/llvm-project#173966
Commit to cherry-pick
5ed875a06cb0a6d543f719ad72df2a1660e42cb9
I am using a supported NDK
Affected versions
r27 (probably all, including 30-beta-1)
Host OS
Mac
Host OS version
macOS 26.4.1
Affected ABIs
arm64-v8a