[BUG] Breakpoints never hit in native code when using LLD #885
Comments
|
@stephenhines: how do you want to handle lldb bugs? |
|
This is an LLD bug, right? Or am I misunderstanding things? |
|
until someone tries with gdb i'm not sure we can tell, since the submitter is using lld and lldb. (the fact that lldb and gold work does suggest it might be lld rather than lldb that's at fault though.) |
|
Could also be lld doing something valid but different from gold that lldb doesn't expect. Fortunately it's all for @stephenhines either way, so same question :) |
|
Did this happen on macOS? |
I have not tried with other environments. |
|
@chih-hung: |
|
@chih-hung, this is still an issue with NDK 20. The NDK release notes are encouraging LLD usage / testing, but this issue prevents broader adoption beyond. Any update on progress or potential workarounds? |
|
Need to figure out whether this is an lldb or lld issue. Using ndk-gdb with Studio is a hassle, but you can set up symlinks to make it happy. We have an example of this here: https://android.googlesource.com/platform/ndk/+/refs/heads/master/samples/NdkGdbSample/. @stephenhines @chih-hung: could one of you give that a shot? Hopefully you can just switch that sample to lld and repro the issue with lldb, and then switch to ndk-gdb to confirm. If not, can start copying code from the repro case until it repros. (@steveprentice if that's something you have time to verify we'd greatly appreciate it, otherwise we'll have a look when we have the time) |
|
I was able to confirm it. When I use i.e. bfd: lld: The intermediate solib (app/build/intermediates/cmake/debug/obj/arm64-v8a/libnative-lib.so) has different build IDs with bfd versus lld: The file in the lldb module cache is stripped: The lld build ID is shorter than the bfd build ID, and there's a disagreement. |
|
The lldb in Studio appears to accept only 16- or 20-byte build IDs. lld defaults to an 8-byte hash as its build ID (https://reviews.llvm.org/D18091). When the 8-byte ID was added to lld, lldb was also patched to accept anything between 4 and 20 bytes (https://reviews.llvm.org/D18096). (Studio's lldb is a little out of date...) I'm able to get lld debugging working by adding cmake_minimum_required(VERSION 3.4.1)
# -fno-experimental-isel works around https://github.com/android-ndk/ndk/issues/1004 in NDK r20.
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -fno-experimental-isel")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fuse-ld=lld -Wl,--build-id=sha1")About that linker argument: It looks like only the last I think we can replace the |
|
Awesome, that means we can fix this for r21 and people can fix this up on r20 on their own if they need to. We'll still want an updated lldb in Studio, but this at least unblocks lld. |
|
(also, does gdb support the 8 byte hash, or will we need a similar fix for gdb?) |
|
Switching char blob[100000000] = { 1 };
int main() {}Using a Windows machine with 1000 iterations: Switching from I'm guessing this isn't enough of a regression to be a concern, but if it is, we could:
|
|
Running the same test on my Linux workstation shows a regression of 300ms to 377ms (+26%). |
We only do that for ndk-build, though, not CMake, so that's probably not an option. |
(in case you were wondering why, we can't do it reliably for CMake because our only chance to do anything in CMake is in the toolchain file, so we can't see anything that the user does in their CMakeLists.txt) |
I verified that gdb 7.11 can find a library using its build ID if the build ID is 4, 8, or 16 bytes. AFAICT, gdb handles any non-zero build ID size. To test this, I copied an unstripped library to diff --git a/scripts/gdbclient.py b/scripts/gdbclient.py
index e3a050330..f09d3b9a9 100755
--- a/scripts/gdbclient.py
+++ b/scripts/gdbclient.py
@@ -268,8 +268,9 @@ def generate_gdb_script(root, sysroot, binary_name, port, dalvik_gdb_script, sol
gdb_commands = ""
gdb_commands += "file '{}'\n".format(binary_name)
gdb_commands += "directory '{}'\n".format(root)
- gdb_commands += "set solib-absolute-prefix {}\n".format(sysroot)
- gdb_commands += "set solib-search-path {}\n".format(solib_search_path)
+ gdb_commands += "set debug-file-directory {}\n".format(sysroot)
+ #gdb_commands += "set solib-absolute-prefix {}\n".format(sysroot)
+ #gdb_commands += "set solib-search-path {}\n".format(solib_search_path)
if dalvik_gdb_script:
gdb_commands += "source {}\n".format(dalvik_gdb_script)
FWIW, the platform defaults to 16-byte IDs ( |
|
The fix is in aosp/master and should go into NDK r21: Once Android Studio's LLDB is updated, I think we'll revert this change and let the linker pick its own build ID hash method. e.g. lld would compute an 8-byte xxHash ID. We should probably also enable |
lld defaults to an 8-byte hash (--build-id=fast), but Android Studio's current version of lldb only recognizes 16- and 20-byte hashes (--build-id=[md5,sha1,tree,uuid]). Specify --build-id=sha1 to explicitly use a 20-byte hash for the build ID. This setting can be removed once lldb is updated. Bug: android/ndk#885 Test: build and debug NDK app in Android Studio Test: run `file` on NDK libnative-lib.so Change-Id: I2e5f2d37817c7855bd704eb05241eba4c1d02a52
Using sha1 instead of tree turned out to have a larger build impact
than the benchmarking suggested (10% regression in dolphin build
time).
For ndk-build, scan all the linker flags for -fuse-ld and check
APP_LD to determine if lld is being used, and if it is then fallback
to tree. Otherwise, use the linker default.
For CMake we don't know the user's chosen ldflags, so the best we can
do is work off of ANDROID_LD. If the user doesn't use ANDROID_LD and
instead uses -fuse-ld=lld explicitly, they won't be able to debug.
Test: inspected verbose build output for the following configurations:
* No flags
* APP_LD=lld
* APP_LD=gold
* APP_LD=lld APP_LDFLAGS=-fuse-ld=gold
* APP_LD=gold APP_LDFLAGS=-fuse-ld=lld
* For the first three variants, checked CMake with ANDROID_LD.
Bug: http://b/143411084
Bug: android/ndk#885
Change-Id: I62a7b6a296a61bc543c38d406bfb9f15ddb1c7fa
Using sha1 instead of tree turned out to have a larger build impact
than the benchmarking suggested (10% regression in dolphin build
time).
For ndk-build, scan all the linker flags for -fuse-ld and check
APP_LD to determine if lld is being used, and if it is then fallback
to tree. Otherwise, use the linker default.
For CMake we don't know the user's chosen ldflags, so the best we can
do is work off of ANDROID_LD. If the user doesn't use ANDROID_LD and
instead uses -fuse-ld=lld explicitly, they won't be able to debug.
Test: inspected verbose build output for the following configurations:
* No flags
* APP_LD=lld
* APP_LD=gold
* APP_LD=lld APP_LDFLAGS=-fuse-ld=gold
* APP_LD=gold APP_LDFLAGS=-fuse-ld=lld
* For the first three variants, checked CMake with ANDROID_LD.
Bug: http://b/143411084
Bug: android/ndk#885
Change-Id: I62a7b6a296a61bc543c38d406bfb9f15ddb1c7fa
(cherry picked from commit 8ebd5e0)
Using sha1 instead of tree turned out to have a larger build impact
than the benchmarking suggested (10% regression in dolphin build
time).
For ndk-build, scan all the linker flags for -fuse-ld and check
APP_LD to determine if lld is being used, and if it is then fallback
to tree. Otherwise, use the linker default.
For CMake we don't know the user's chosen ldflags, so the best we can
do is work off of ANDROID_LD. If the user doesn't use ANDROID_LD and
instead uses -fuse-ld=lld explicitly, they won't be able to debug.
Test: inspected verbose build output for the following configurations:
* No flags
* APP_LD=lld
* APP_LD=gold
* APP_LD=lld APP_LDFLAGS=-fuse-ld=gold
* APP_LD=gold APP_LDFLAGS=-fuse-ld=lld
* For the first three variants, checked CMake with ANDROID_LD.
Bug: http://b/143411084
Bug: android/ndk#885
Change-Id: I62a7b6a296a61bc543c38d406bfb9f15ddb1c7fa
(cherry picked from commit 8ebd5e0)
Using sha1 instead of tree turned out to have a larger build impact
than the benchmarking suggested (10% regression in dolphin build
time).
For ndk-build, scan all the linker flags for -fuse-ld and check
APP_LD to determine if lld is being used, and if it is then fallback
to tree. Otherwise, use the linker default.
For CMake we don't know the user's chosen ldflags, so the best we can
do is work off of ANDROID_LD. If the user doesn't use ANDROID_LD and
instead uses -fuse-ld=lld explicitly, they won't be able to debug.
Test: inspected verbose build output for the following configurations:
* No flags
* APP_LD=lld
* APP_LD=gold
* APP_LD=lld APP_LDFLAGS=-fuse-ld=gold
* APP_LD=gold APP_LDFLAGS=-fuse-ld=lld
* For the first three variants, checked CMake with ANDROID_LD.
Bug: http://b/143411084
Bug: android/ndk#885
Change-Id: I62a7b6a296a61bc543c38d406bfb9f15ddb1c7fa
(cherry picked from commit 8ebd5e0)
Description
I wasn't sure if this should be submitted here or against Android Studio, but decided to start here since the NDK changelog is asking for people to start testing with LLD. Let me know if you need me to resubmit against Android Studio.
Java_com_sample_lld_MainActivity_stringFromJNI()Reverting back to the gold linker solves the issue.
Sample app: https://github.com/steveprentice/lld-breakpoint
Environment Details
Android Studio 3.3 RC3
NDK r18b, r19 beta2 and latest canary 5221128.
macOS
The text was updated successfully, but these errors were encountered: