Repository navigation
r26 armeabi-v7a libc++ probably not built as thumb #1953
Description
Description
Merely switching from 25.1.8937393 to 26.1.10909125 causes my .so files to decrease somewhat in size, except for arm64-v8a. Is this expected?
Also, the libc++_shared.so is larger for all ABIs. Also expected?
| Library | ABI | r25 (bytes) | r26 (bytes) |
| ---------------- | ----------- |-------------:|-------------:|
| mylib.so | arm64-v8a | 2 395 376 | 2 465 384 | <---
| mylib.so | armeabi-v7a | 2 231 984 | 2 229 208 |
| mylib.so | x86 | 2 755 532 | 2 718 636 |
| mylib.so | x86_64 | 2 727 504 | 2 679 816 |
| libc++_shared.so | arm64-v8a | 1 026 616 | 1 330 832 | ?
| libc++_shared.so | armeabi-v7a | 610 272 | 1 109 732 | ?
| libc++_shared.so | x86 | 993 108 | 1 284 616 | ?
| libc++_shared.so | x86_64 | 1 045 960 | 1 275 840 | ?
I did set minSdk 21 in build.gradle, but my Application.mk (accidently) contained APP_PLATFORM := android-19, so I'm not entirely sure which SDK was configured for the NDK build. It should be noted that mylib.so is built in a project which depends on an .AAR (where APP_STRIP_MODE was set to none). Otherwise, no fancy settings.
Application.mk
APP_PLATFORM := android-21
APP_ABI := armeabi-v7a x86 arm64-v8a x86_64
APP_STL := c++_sharedAttaching the .so files for arm64-v8a:
arm64-libs.zip
Affected versions
r26
Canary version
No response
Host OS
Windows
Host OS version
Windows 11
Affected ABIs
armeabi-v7a, arm64-v8a, x86, x86_64
Build system
ndk-build
Other build system
No response
minSdkVersion
21
Device API level
No response
Activity
DanAlbert commentedon Oct 23, 2023
Tentatively triaging to r26c. These are often quite difficult to diagnose when they weren't the result of something we did on purpose, and they're generally caused by upstream LLVM changes, and that can be anything from a change in optimization behavior to a correctness fix.
@pirama-arumuga-nainar could one of you have a look and see if you can come up with an explanation?
appujee commentedon Oct 24, 2023
the libc++_shared.so in r26 has more symbols.
only_in_r25.txt
only_in_r26.txt
DanAlbert commentedon Oct 24, 2023
Is that the reason for mylib.so growing though?
This is drastic enough that I'd bet the LLVM build doesn't build the runtimes as thumb... @rprichard
(the other architectures grew, but considering we were quite behind on libc++, it's not surprising that they've added more code to libc++ in that time)
appujee commentedon Oct 24, 2023
For the specific binary liborxDemo.so shared in the bug report. the biggest contributors are .text and .ehframe
appujee commentedon Oct 24, 2023
He is a detailed breakdown of the symbols if anyone is interested in doing further analysis. It will take a while to find specific symbols but if the bug author is super interested, these files have sufficient information.
r25.csv
r26.csv
[-]r26 produces larger .so file for arm64-v8a (and libc++_shared.so larger for all ABIs)[/-][+]r26 armeabi-v7a libc++ probably not built as thumb[/+]DanAlbert commentedon Nov 1, 2023
The toolchain folks say that the size increase for arm64 is within the expected range (new compiler means new behavior, different optimization decisions, and this size difference is within what we expect for that).
The arm32 libc++ size increase does look like it wasn't built as thumb though (libc++ moved from the NDK to being part of the toolchain in r26, so the build process was redone). That's a thing we ought to fix.
That alone won't be the trigger for r26c, but we'll pick up that fix in r26c when something else inevitably does.
pirama-arumuga-nainar commentedon Nov 7, 2023
With https://android-review.googlesource.com/c/toolchain/llvm_android/+/2814878, the size of the arm libc++.so is 888K - it's still larger than r25 but it is expected with new compiler and libc++ (and in line with the rest of the platforms.)
znakeeye commentedon Dec 1, 2023
You know this better than me. But in our AAR project, we do set
LOCAL_ARM_MODE := armwhen building the library from prefabs. When the AAR is consumed by the app project, we do the same. Maybe this is related?9 remaining items
Build arm32 libc++ for the NDK with -mthumb
Bump NDK to r26c (#8732)
Build arm32 libc++ for the NDK with -mthumb
Note r26c LLVM fixes in the changelog.
Update LLVM to r522817.
Build arm32 libc++ for the NDK with -mthumb