使用 Android Studio 调试 C++ 库
Debugging C++ library with Android Studio
我正在开发一个 Android
项目,该项目使用 Java
class,它是 C++
库的包装器。 C++库是公司内部库,我们可以访问它的源代码,但是在Android项目中只是动态链接,所以只以头文件的形式使用(.h ) 和共享对象 (.so)。可以访问库源代码,是否可以向 Android Studio 指定源代码的路径,以便我可以使用调试器进入库?
调试器工作,我可以进入 Java_clory_engine_sdk_CloryNative_nativeInit
函数,但我还想进一步调试对应于 Clory::Engine
class 的库,正如我提到的,是我们可以访问源代码的内部库。
例如,Clory::Engine::instance
是库的一部分,我想向 Android Studio 指定 CloryEngine.cpp
文件的位置,以便我可以进入 Clory::Engine::instance
配合调试器,从而调试这个静态成员函数。
我正在使用 Android Studio 3.1.4.
这可能吗?
编辑:
clory-sdk.gradle
文件指定配置C++层的CMakeLists.txt
文件。
externalNativeBuild {
cmake {
path "CMakeLists.txt"
}
}
所以我正在使用一个使用 Clory SDK 的内部应用程序。在我使用的 app.gradle
文件中:
dependencies {
...
compile project(':clory-sdk-core')
compile project(':clory-sdk')
...
}
所以我不认为我们在 app.gradle
项目中使用 aar
s。 aar
s 被运送到客户端,但我们正在使用 app.gradle
项目来测试我们的小 SDK 功能,然后再这样做。 JNI 层在 clory-sdk-core
项目内。
编辑 2:
这是处理 JNI 层的 CMakeLists.txt
:
cmake_minimum_required(VERSION 3.4.1)
set(CMAKE_AUTOMOC ON)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_BUILD_TYPE Debug)
add_library(
clory-lib
SHARED
# JNI layer and other helper classes for transferring data from Java to Qt/C++
src/main/cpp/clory-lib.cpp
src/main/cpp/JObjectHandler.cpp
src/main/cpp/JObjectResolver.cpp
src/main/cpp/JObjectCreator.cpp
src/main/cpp/DataConverter.cpp
src/main/cpp/JObjectHelper.cpp
src/main/cpp/JEnvironmentManager.cpp
)
find_library(
log-lib
log
)
target_compile_options(clory-lib
PUBLIC
-std=c++11
)
# Hardcoded for now...will fix later...
set(_QT_ROOT_PATH /Users/jacob/Qt/5.8)
if(${ANDROID_ABI} MATCHES ^armeabi-v7.*$)
set(_QT_ARCH android_armv7)
elseif(${ANDROID_ABI} MATCHES ^x86$)
set(_QT_ARCH android_x86)
else()
message(FATAL_ERROR "Unsupported Android architecture!!!")
endif()
set(CMAKE_FIND_ROOT_PATH ${_QT_ROOT_PATH}/${_QT_ARCH})
find_package(Qt5 REQUIRED COMPONENTS
Core
CONFIG
)
target_include_directories(clory-lib
PUBLIC
${CMAKE_CURRENT_LIST_DIR}/src/main/cpp
)
set(_CLORYSDK_LIB_PATH ${CMAKE_CURRENT_LIST_DIR}/src/main/jniLibs/${ANDROID_ABI})
target_link_libraries(clory-lib
${log-lib}
-L${_CLORYSDK_LIB_PATH}
clorysdk
Qt5::Core
)
库clorysdk
实际上是我所说的我们的内部库,其中包含例如Clory::Engine::instance
我想进入调试器。它是用 qmake
构建的,并且是在调试模式下构建的(CONFIG+=debug
是在有效的 qmake 调用中添加的)。
编辑 3:
在遇到 Java_clory_engine_sdk_CloryNative_nativeInit
断点后打开的 LLDB
会话中,我得到以下信息:
(lldb) image lookup -vrn Clory::Engine::instance
2 matches found in /Users/jacob/.lldb/module_cache/remote-android/.cache/6EDE4F0A-0000-0000-0000-000000000000/libclorysdk.so:
Address: libclorysdk.so[0x0001bb32] (libclorysdk.so..text + 8250)
Summary: libclorysdk.so`Clory::Engine::instance(Clory::Engine::Purpose)
Module: file = "/Users/jacob/.lldb/module_cache/remote-android/.cache/6EDE4F0A-0000-0000-0000-000000000000/libclorysdk.so", arch = "arm"
Symbol: id = {0x0000005e}, range = [0xcb41eb32-0xcb41ebc0), name="Clory::Engine::instance(Clory::Engine::Purpose)", mangled="_ZN4Clory2Engine8instanceENS0_7PurposeE"
Address: libclorysdk.so[0x0001b82c] (libclorysdk.so..text + 7476)
Summary: libclorysdk.so`Clory::Engine::instance(Clory::RuntimeConfiguration const&, Clory::Engine::Purpose)
Module: file = "/Users/jacob/.lldb/module_cache/remote-android/.cache/6EDE4F0A-0000-0000-0000-000000000000/libclorysdk.so", arch = "arm"
Symbol: id = {0x000000bd}, range = [0xcb41e82c-0xcb41e970), name="Clory::Engine::instance(Clory::RuntimeConfiguration const&, Clory::Engine::Purpose)", mangled="_ZN4Clory2Engine8instanceERKNS_20RuntimeConfigurationENS0_7PurposeE"
(lldb) settings show target.source-map
target.source-map (path-map) =
首先,命令image lookup -vrn Clory::Engine::instance
的结果中没有CompileUnit
部分。如果 libclorysdk.so
是在 调试模式?是否可以显式设置它以便调试器在那里搜索库的源文件?
编辑 4:
经过更多搜索后,我发现创建 APK 的过程实际上从调试符号中删除了 *.so
库。 libclorysdk.so
内置调试模式大约有 10MB,而我解压缩生成的 *.apk
文件后提取的 libclorysdk.so
文件只有 350KB。
如 here 所述,调试版本上的 运行ning greadelf --debug-dump=decodedline libclorysdk.so
输出对源文件的引用,但如果命令是 *.apk
提取库上的 运行,它什么都不输出。
有没有办法阻止 Android Studio 剥离 *.so
s?我尝试了 但没有任何效果,*.apk
文件大小与以前相同,调试本机库仍然无效。
我正在使用 Gradle 3.1.4
。
编辑 5:
有效,但就我而言,它需要在到达库中的断点之前进行清理和构建。部署未剥离的 *.so
允许您进行调试会话并进入本机库。
注:
如果库是使用 Qt for Android
工具链构建的,部署到 $SHADOW_BUILD/android-build
的 *.so
也会被删除(其中 $SHADOW_BUILD
是构建目录通常以 build-*
开头)。因此,为了调试它们,您应该从生成每个 *.so
的 android-build
目录外部复制它们。
调试信息记录了源文件生成时的位置。
(lldb) image lookup -vrn Clory::Engine::instance
CompileUnit 行显示了源文件。假设它说:
"/BuildDirectory/Sources/Clory/CloryEngine.cpp"
假设您的计算机上有源代码:
"Users/me/Sources/Clory"
所以你可以告诉 lldb:在 Users/me/Sources/Clory 中找到以 /BuildDirectory/Sources/Clory 为根的源文件。
(lldb) settings set target.source-map /BuildDirectory/Sources/Clory Users/me/Sources/Clory
您可以在 Android Studio 的 lldb 控制台中使用这些命令,或者将这些命令放入 .lldbinit 文件中以供一般使用。
如果没有可用的调试符号,您可能必须在调试模式下构建引用的库。
与-DCMAKE_BUILD_TYPE=DEBUG
:
defaultConfig {
externalNativeBuild {
cmake {
arguments "-DANDROID_TOOLCHAIN=gcc", "-DCMAKE_BUILD_TYPE=DEBUG"
cppFlags "-std=c++14 -fexceptions -frtti"
}
}
}
externalNativeBuild {
cmake {
path file('src/main/cpp/CMakeLists.txt')
}
}
或将此添加到库的 CMakeLists.txt
:
set(CMAKE_BUILD_TYPE Debug)
参见CMake documentation and Symbolicating with LLDB。
Elsewhere 它解释了 (lldb) settings set target.source-map /buildbot/path /my/path
:
Remap source file path-names for the debug session. If your source files are no longer located in the same location as when the program was built --- maybe the program was built on a different computer --- you need to tell the debugger how to find the sources at their local file path instead of the build system's file path.
还有(lldb) settings show target.source-map
,看看映射了什么。
(lldb) set append target.source-map /buildbot/path /my/path
似乎很合适,以免覆盖现有映射。
我正在开发一个 Android
项目,该项目使用 Java
class,它是 C++
库的包装器。 C++库是公司内部库,我们可以访问它的源代码,但是在Android项目中只是动态链接,所以只以头文件的形式使用(.h ) 和共享对象 (.so)。可以访问库源代码,是否可以向 Android Studio 指定源代码的路径,以便我可以使用调试器进入库?
调试器工作,我可以进入 Java_clory_engine_sdk_CloryNative_nativeInit
函数,但我还想进一步调试对应于 Clory::Engine
class 的库,正如我提到的,是我们可以访问源代码的内部库。
例如,Clory::Engine::instance
是库的一部分,我想向 Android Studio 指定 CloryEngine.cpp
文件的位置,以便我可以进入 Clory::Engine::instance
配合调试器,从而调试这个静态成员函数。
我正在使用 Android Studio 3.1.4.
这可能吗?
编辑:
clory-sdk.gradle
文件指定配置C++层的CMakeLists.txt
文件。
externalNativeBuild {
cmake {
path "CMakeLists.txt"
}
}
所以我正在使用一个使用 Clory SDK 的内部应用程序。在我使用的 app.gradle
文件中:
dependencies {
...
compile project(':clory-sdk-core')
compile project(':clory-sdk')
...
}
所以我不认为我们在 app.gradle
项目中使用 aar
s。 aar
s 被运送到客户端,但我们正在使用 app.gradle
项目来测试我们的小 SDK 功能,然后再这样做。 JNI 层在 clory-sdk-core
项目内。
编辑 2:
这是处理 JNI 层的 CMakeLists.txt
:
cmake_minimum_required(VERSION 3.4.1)
set(CMAKE_AUTOMOC ON)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_BUILD_TYPE Debug)
add_library(
clory-lib
SHARED
# JNI layer and other helper classes for transferring data from Java to Qt/C++
src/main/cpp/clory-lib.cpp
src/main/cpp/JObjectHandler.cpp
src/main/cpp/JObjectResolver.cpp
src/main/cpp/JObjectCreator.cpp
src/main/cpp/DataConverter.cpp
src/main/cpp/JObjectHelper.cpp
src/main/cpp/JEnvironmentManager.cpp
)
find_library(
log-lib
log
)
target_compile_options(clory-lib
PUBLIC
-std=c++11
)
# Hardcoded for now...will fix later...
set(_QT_ROOT_PATH /Users/jacob/Qt/5.8)
if(${ANDROID_ABI} MATCHES ^armeabi-v7.*$)
set(_QT_ARCH android_armv7)
elseif(${ANDROID_ABI} MATCHES ^x86$)
set(_QT_ARCH android_x86)
else()
message(FATAL_ERROR "Unsupported Android architecture!!!")
endif()
set(CMAKE_FIND_ROOT_PATH ${_QT_ROOT_PATH}/${_QT_ARCH})
find_package(Qt5 REQUIRED COMPONENTS
Core
CONFIG
)
target_include_directories(clory-lib
PUBLIC
${CMAKE_CURRENT_LIST_DIR}/src/main/cpp
)
set(_CLORYSDK_LIB_PATH ${CMAKE_CURRENT_LIST_DIR}/src/main/jniLibs/${ANDROID_ABI})
target_link_libraries(clory-lib
${log-lib}
-L${_CLORYSDK_LIB_PATH}
clorysdk
Qt5::Core
)
库clorysdk
实际上是我所说的我们的内部库,其中包含例如Clory::Engine::instance
我想进入调试器。它是用 qmake
构建的,并且是在调试模式下构建的(CONFIG+=debug
是在有效的 qmake 调用中添加的)。
编辑 3:
在遇到 Java_clory_engine_sdk_CloryNative_nativeInit
断点后打开的 LLDB
会话中,我得到以下信息:
(lldb) image lookup -vrn Clory::Engine::instance
2 matches found in /Users/jacob/.lldb/module_cache/remote-android/.cache/6EDE4F0A-0000-0000-0000-000000000000/libclorysdk.so:
Address: libclorysdk.so[0x0001bb32] (libclorysdk.so..text + 8250)
Summary: libclorysdk.so`Clory::Engine::instance(Clory::Engine::Purpose)
Module: file = "/Users/jacob/.lldb/module_cache/remote-android/.cache/6EDE4F0A-0000-0000-0000-000000000000/libclorysdk.so", arch = "arm"
Symbol: id = {0x0000005e}, range = [0xcb41eb32-0xcb41ebc0), name="Clory::Engine::instance(Clory::Engine::Purpose)", mangled="_ZN4Clory2Engine8instanceENS0_7PurposeE"
Address: libclorysdk.so[0x0001b82c] (libclorysdk.so..text + 7476)
Summary: libclorysdk.so`Clory::Engine::instance(Clory::RuntimeConfiguration const&, Clory::Engine::Purpose)
Module: file = "/Users/jacob/.lldb/module_cache/remote-android/.cache/6EDE4F0A-0000-0000-0000-000000000000/libclorysdk.so", arch = "arm"
Symbol: id = {0x000000bd}, range = [0xcb41e82c-0xcb41e970), name="Clory::Engine::instance(Clory::RuntimeConfiguration const&, Clory::Engine::Purpose)", mangled="_ZN4Clory2Engine8instanceERKNS_20RuntimeConfigurationENS0_7PurposeE"
(lldb) settings show target.source-map
target.source-map (path-map) =
首先,命令image lookup -vrn Clory::Engine::instance
的结果中没有CompileUnit
部分。如果 libclorysdk.so
是在 调试模式?是否可以显式设置它以便调试器在那里搜索库的源文件?
编辑 4:
经过更多搜索后,我发现创建 APK 的过程实际上从调试符号中删除了 *.so
库。 libclorysdk.so
内置调试模式大约有 10MB,而我解压缩生成的 *.apk
文件后提取的 libclorysdk.so
文件只有 350KB。
如 here 所述,调试版本上的 运行ning greadelf --debug-dump=decodedline libclorysdk.so
输出对源文件的引用,但如果命令是 *.apk
提取库上的 运行,它什么都不输出。
有没有办法阻止 Android Studio 剥离 *.so
s?我尝试了 *.apk
文件大小与以前相同,调试本机库仍然无效。
我正在使用 Gradle 3.1.4
。
编辑 5:
*.so
允许您进行调试会话并进入本机库。
注:
如果库是使用 Qt for Android
工具链构建的,部署到 $SHADOW_BUILD/android-build
的 *.so
也会被删除(其中 $SHADOW_BUILD
是构建目录通常以 build-*
开头)。因此,为了调试它们,您应该从生成每个 *.so
的 android-build
目录外部复制它们。
调试信息记录了源文件生成时的位置。
(lldb) image lookup -vrn Clory::Engine::instance
CompileUnit 行显示了源文件。假设它说:
"/BuildDirectory/Sources/Clory/CloryEngine.cpp"
假设您的计算机上有源代码:
"Users/me/Sources/Clory"
所以你可以告诉 lldb:在 Users/me/Sources/Clory 中找到以 /BuildDirectory/Sources/Clory 为根的源文件。
(lldb) settings set target.source-map /BuildDirectory/Sources/Clory Users/me/Sources/Clory
您可以在 Android Studio 的 lldb 控制台中使用这些命令,或者将这些命令放入 .lldbinit 文件中以供一般使用。
如果没有可用的调试符号,您可能必须在调试模式下构建引用的库。
与-DCMAKE_BUILD_TYPE=DEBUG
:
defaultConfig {
externalNativeBuild {
cmake {
arguments "-DANDROID_TOOLCHAIN=gcc", "-DCMAKE_BUILD_TYPE=DEBUG"
cppFlags "-std=c++14 -fexceptions -frtti"
}
}
}
externalNativeBuild {
cmake {
path file('src/main/cpp/CMakeLists.txt')
}
}
或将此添加到库的 CMakeLists.txt
:
set(CMAKE_BUILD_TYPE Debug)
参见CMake documentation and Symbolicating with LLDB。
Elsewhere 它解释了 (lldb) settings set target.source-map /buildbot/path /my/path
:
Remap source file path-names for the debug session. If your source files are no longer located in the same location as when the program was built --- maybe the program was built on a different computer --- you need to tell the debugger how to find the sources at their local file path instead of the build system's file path.
还有(lldb) settings show target.source-map
,看看映射了什么。
(lldb) set append target.source-map /buildbot/path /my/path
似乎很合适,以免覆盖现有映射。