Re: [lldb-dev] lldb-server stripped binary size: AArch64 ~16Mb vs ARM ~9 Mb
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...) On Tue, Mar 1, 2016 at 10:47 AM Mikhail Filimonov wrote: > 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 > > > > *From:* Tamas Berghammer [mailto:tbergham...@google.com] > *Sent:* Tuesday, March 1, 2016 1:34 PM > *To:* Pavel Labath ; Mikhail Filimonov < > mfilimo...@nvidia.com> > > > *Cc:* lldb-dev@lists.llvm.org > *Subject:* Re: [lldb-dev] lldb-server stripped binary size: AArch64 ~16Mb > vs ARM ~9 Mb > > > > 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 > > > > On Tue, Mar 1, 2016 at 9:18 AM Pavel Labath via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > 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 > > On 29 February 2016 at 20:15, Mikhail Filimonov via lldb-dev > wrote: > > 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_TAB
Re: [lldb-dev] [Release-testers] [3.8 Release] RC3 has been tagged
> > > clang+llvm-3.8.0-rc3-mipsel-linux-gnu.tar.xz > > > My machine died during the check-all stage and disappeared from > > > the > > network. I've fixed it and am currently running the last few bits of test- > > release.sh manually. > > > > Thanks, let me know how this turns out. > > > > So far, it sounds like there are no new issues in rc3, so I'm hoping > > we can make that the final version for 3.8.0 real soon. > > > > Cheers, > > Hans > > > > 'check-all' is still killing the machine but I think I know what the problem > is. While investigating some of the rc2 > problems I noticed that g++-multilib wasn't installed and this was disabling > the mips64el sanitizers. Installing this > didn't cause problems at the time but I've noticed that some of the mips64el > sanitizer tests are very memory hungry. > I noticed several occasions where parallel asan tests were consuming ~200% of > RAM and it would have been > swapping heavily (on a USB2 disk) to cope. If later tests require even more > RAM then it would explain why the > system stops responding. I'm going to uninstall g++-multilib and rebuild rc3. > Hopefully that will make check-all work > again. It seems there's was still just enough multilib support on the machine to trigger mips64el sanitizers again but having worked around that the parts of lit that aren't mips64el sanitizers are working so far. llvm-lit is still going but big-endian mips and cross compilation was fine so I'm expecting little endian to be ok too. It's showing an ETA of about 90 mins for the remaining tests from clang and llvm at the moment. I'm going to run the MIPS32 sanitizer lit tests after that. Overall, I think we're probably ready for final. I just can't confirm that rc3 was definitely ok for little endian mips yet. > For now, I've commented out the check-all command and uploaded > clang+llvm-3.8.0-rc3-mipsel-linux-gnu.tar.xz > (sha1sum: e280bf6db094a81f22f4cdf6c0b5955493a11b05). I'm going to run this > through my usual test-suites and I > should have the results by this evening. The LNT test-suite runs were ok with the rc3 build. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [3.8 Release] 'final' has been tagged
Dear testers, My list of blockers is empty, and there were no new problems discovered with rc3, so I have gone ahead and tagged 3.8.0-final [1]. Please build the final binaries and upload to the sftp. For others following along: yes, this means 3.8.0 is complete, but it takes a couple of days to get the source and binary tarballs built. I will send the release announcement when everything's ready. Many thanks for all your work! Hans [1]. http://lists.llvm.org/pipermail/llvm-branch-commits/2016-March/009883.html ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [3.8 Release] RC3 has been tagged
> > > > clang+llvm-3.8.0-rc3-mipsel-linux-gnu.tar.xz > > > > My machine died during the check-all stage and disappeared from > > > > the > > > network. I've fixed it and am currently running the last few bits of test- > > > release.sh manually. > > > > > > Thanks, let me know how this turns out. > > > > > > So far, it sounds like there are no new issues in rc3, so I'm hoping > > > we can make that the final version for 3.8.0 real soon. > > > > > > Cheers, > > > Hans > > > > > > > 'check-all' is still killing the machine but I think I know what the > > problem is. While investigating some of the rc2 > > problems I noticed that g++-multilib wasn't installed and this was > > disabling the mips64el sanitizers. Installing this > > didn't cause problems at the time but I've noticed that some of the > > mips64el sanitizer tests are very memory hungry. > > I noticed several occasions where parallel asan tests were consuming ~200% > > of RAM and it would have been > > swapping heavily (on a USB2 disk) to cope. If later tests require even more > > RAM then it would explain why the > > system stops responding. I'm going to uninstall g++-multilib and rebuild > > rc3. Hopefully that will make check-all work > > again. > > It seems there's was still just enough multilib support on the machine to > trigger mips64el sanitizers again but having worked > around that the parts of lit that aren't mips64el sanitizers are working so > far. llvm-lit is still going but big-endian mips and cross > compilation was fine so I'm expecting little endian to be ok too. It's > showing an ETA of about 90 mins for the remaining tests > from clang and llvm at the moment. I'm going to run the MIPS32 sanitizer lit > tests after that. This is proving to be a long 90 mins :-). It's currently at 93% and estimating 15 mins but that estimate has been slowly creeping upwards for the last hour or so. I'll check on it first thing in the morning. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
