r26 armeabi-v7a libc++ probably not built as thumb

[znakeeye]

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++_shared

Attaching 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

[DanAlbert]

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]

the libc++_shared.so in r26 has more symbols.

only_in_r25.txt
only_in_r26.txt

[DanAlbert]

Is that the reason for mylib.so growing though?

| libc++_shared.so | armeabi-v7a | 610 272 | 1 109 732 | ?

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]

For the specific binary liborxDemo.so shared in the bug report. the biggest contributors are .text and .ehframe

section	r25	r26
.eh_frame	171836	207984
.text	1372480	1398416

[appujee]

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

[DanAlbert]

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]

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.)