Hello, fellow developers and congratulations with long awaited 3.8 Release.
I wonder why AArch64 stripped binary of lldb-server built from [3.8 Release] RC3 source is so much bigger than its ARM counterpart.
See the numbers:
16318632 Feb 29 22:41 lldb-server-3.8.0-aarch64
9570916 Feb 29 22:23 lldb-server-3.8.0-arm
lldb-server-3.8.0-aarch64: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
lldb-server-3.8.0-arm: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped
My build configuration is MinSizeRel in both cases:
cmake -GNinja
-DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git
-DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
-DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/aarch64-21-android
-DANDROID_ABI=aarch64
-DCMAKE_CXX_COMPILER_VERSION=4.9
-DLLVM_TARGET_ARCH=aarch64
-DLLVM_HOST_TRIPLE=aarch64-unknown-linux-android
-DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
-DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
cmake -GNinja
-DCMAKE_BUILD_TYPE=MinSizeRel $HOME/llvm_git
-DCMAKE_TOOLCHAIN_FILE=tools/lldb/cmake/platforms/Android.cmake
-DANDROID_TOOLCHAIN_DIR=$HOME/Toolchains/arm-21-android-toolchain
-DANDROID_ABI=armeabi
-DCMAKE_CXX_COMPILER_VERSION=4.9
-DLLVM_TARGET_ARCH=arm
-DLLVM_HOST_TRIPLE=arm-unknown-linux-android
-DLLVM_TABLEGEN=$HOME/llvm_host/bin/llvm-tblgen
-DCLANG_TABLEGEN=$HOME/llvm_host/bin/clang-tblgen
Maybe I need some additional settings to be set for AArch64 case?
Regards,
Mikhail
Hi,
so the problem here is that we are currently relying on the linker to
remove code that we don't need, and it can't always do a good job in
figuring out which code is not used due to complex dependencies. So,
innocent-looking changes in the code can pull in lots of transitive
dependencies, even though they are not used. I suspect something like
that is going on here, although we should keep in mind that arm64 code
is less dense naturally. Any help on this front will be welcome,
although it probably won't be trivial, as we have probably picked off
the low-hanging fruit already.
That said, you may want to try adding LLVM_TARGETS_TO_BUILD=Aarch64 to
your cmake line. We use that, although I can't say how much it affects
the size of the resulting binary.
help that helps,
pl
Thank you for the quick reply, Pavel.
Unfortunately, addition of -DLLVM_TARGETS_TO_BUILD=AArch64 to my cmake configuration hasn't reduced the size of resulting binary on a single byte.
As Pavel mentioned the unreasonable large size for lldb-server is caused by the fact that we are relying on the liker to remove the unused code and it can’t do too good job because we have lot of unreasonable dependencies.
The size difference between arm and arrahc64 caused by several reason:
- On arm we compile to thumb2 instruction set what is in average ~30% smaller then the arm (and aarch64) instruction set. Before this change the size of lldb-server on arm was ~14MB
- We have Safe ICF (identical code folding) enabled for arm what reduces the binary size by 5-10%. It is not enabled for aarch64 because last time I checked there was still some issue in ld.gold when using ICF on aarch64. It should be already fixed upstream but haven’t reached the NDK yet.
- The aarch64 lldb-server capable of debugging both arm and aarch64 applications so it contains a bit more code because of this (e.g. 2 spearate register context)
Optimizing the size of both binary is possible (and we want to do it sooner or later) but because of the reasons I listed the arm one will stay much smaller then the aarch64 one.
Tamas
Hi and thank you for the detailed reply, Tamas.
Ok, so I’ll cope with increased size of lldb-server for AArch64.
As a side note – is there any publicly available roadmap for LLDB on Android, that covers features to implement\issues to fix? I suggest that the community will greatly appreciate to get a glimpse on the direction of development for that target.
Regards,
Mikhail
We try to keep all of our bugs in the public LLVM bug tracker (llvm.org/bugs) under OS=Linux so if you are looking for issues to work on that is a good place to start (the other option is to look for expectedFailures in the test suit). In general most of the issue we have are present on Linux and very few are specific to android.
For new features we don’t have any clear road map. The current primary focus is to improve the quality and the speed of LLDB but cool new features are always welcomed (e.g. software watchpoints, expression evaluation improvements, module debug info support, etc…)