Why is libc++_static.a not compiled with -ffunction-sections and -fdata-sections

[R1kk3r]

Description

When building my Android app with a native library, I chose to use c++_static instead of c++_shared because my code use only a subset (std::string, std:vector and std::map) of the c++ library. The idea was to decrease my APK size as much as possible. Since I have one native library only, using a static c++ library should be safe.

Somehow, it seems that the whole c++ library have been embedded inside my tiny native library. The flag --gc-sections has not effect and looking with objdump it seems that the object files of libc++_static.a were not compiled with -ffunction-sections -fdata-sections. Is there any reason for that?

Environment Details

• NDK Version: ndk 16, ndk 17
• Build system: cmake
• Host OS: Mac
• Compiler: Clang
• ABI: arm64-v8a
• STL: c++_static
• NDK API level: 21

[enh]

i think pirama is already looking at this in the context of openmp...

[DanAlbert]

I noticed recently that ndk-build only uses -ffunction-sections by default, not -fdata-sections (it does --gc-sections). We use ndk-build to build libc++, so I just need to fix that.

[stephenhines]

Although this makes things smaller for the .a files, it will make the .so files larger. Pirama is indeed looking at this for OpenMP, and it isn't clear that -fdata-sections is a win.

[DanAlbert]

Although this makes things smaller for the .a files, it will make the .so files larger.

Isn't that only true if you forget --gc-sections?

[stephenhines]

I'm talking about libc++_shared.so and things like that where you can't arbitrarily strip out functions that you aren't using. Yes, --gc-sections is often a nice win, but it has to be weighted against what the goals of the shared object are. For prebuilt libraries, you are going to see a different set of tradeoffs.

[pirama-arumuga-nainar]

While testing https://android-review.googlesource.com/c/toolchain/llvm_android/+/719087, I found that the static libraries in the Clang runtimes got bigger as expected. The shared libraries got smaller, as one would expect with gc-sections, for all architectures except aarch64.

@stephenhines hypothesizes that the stricter alignment requirements for functions in aarch64 gets carried to the shared library during linking, even though the functions don't get separate sections in the shared library. I have to verify this or identify a different cause. As mentioned in the previous comment, gc-sections does not get big wins in libraries like libc++.so, where every symbol is potentially useful.

[DanAlbert]

I'm talking about libc++_shared.so and things like that where you can't arbitrarily strip out functions that you aren't using.

Ah, duh. I was thinking you meant the user's library.

[pirama-arumuga-nainar]

The shared libraries got smaller, as one would expect with gc-sections, for all architectures except aarch64.

The increase for aarch64 was against the current clang in r18. The difference stems due to changes unrelated to ffunction-sections - likely due to switching to lld. With LLD, the text and data sections are aligned to 64K and the libraries are larger by ~100K. So there shouldn't be any increase from adding these flags for libc++.

[stephenhines]

There's another issue open about the huge alignment requirements. We could certainly lower that threshold for text/data and still preserve correctness. For libraries like this, perhaps that is more important.

[R1kk3r]

Correct me if I'm wrong but -ffunction-sections and -fdata-sections basically create a section for each function (which allow stripping using --gc-sections afterwards). Thus, due to this section separation, I guess that some of the compiler optimisations cannot be applied anymore. I read somewhere that using such flags makes the code slower as well.

In my case, using the libc++.a instead of the libc++.so is mostly because of a size issue which makes sense to compile libc++.a with those flags. I may be wrong, but I don't think that the scenario where a project makes use of the whole libc++ API (in which case compiling without those flags could make sense since the whole code will be used anyway) is a common use case. Personally, I don't really care if the code is a bit slower.

On the other hand, compiling the libc++.so with those flags does not make sense to me since the purpose of the shared library is to offer a complete API set. In that case, those flags will just produce slower and maybe even bigger code.