[question] NDK 21: how to get rid of source filenames in .so?

[biasmv]

We are currently trying to switch to NDK 21 from r18b. In NDK 21, when building a shared object file, it appears that the source file names are included in the resulting .so file. What's the best way to get rid of those filenames from the .so file?

This behaviour can be reproduced with the following setup:

> cat foo.cpp
extern "C" void foo_function() {}
> cat CMakeLists.txt
project(AndroidStripTest CXX)
add_library(
    foo SHARED
    foo.cpp
)
> mkdir build
> cd build
> cmake -DCMAKE_TOOLCHAIN_FILE=$NDK_ROOT/build/cmake/android.toolchain.cmake \
             -DANDROID_ABI=arm64-v8a \
             -DCMAKE_BUILD_TYPE=Release \
             -DANDROID_STL=none
> make
> export TOOLCHAIN=$NDK_ROOT/toolchains/llvm/prebuilt/darwin-x86_64
> $TOOLCHAIN/bin/llvm-objcopy --strip-debug \
        --discard-all libfoo.so libfoo-stripped.so
> strings libfoo-stripped.so | grep foo.cpp
foo.cpp

Tested with NDK Version: 21.0.6113669

[DanAlbert]

objdump the library and see where it's being referenced, I suppose.

[rprichard]

It looks like llvm-objcopy --strip-debug leaves FILE symbols around, whereas binutils' objcopy --strip-debug removes them.

$ $TOOLCHAIN/bin/llvm-objcopy --strip-debug libfoo.so  libfoo-stripped.so && readelf -s libfoo-stripped.so  | grep FILE
    20: 0000000000000000     0 FILE    LOCAL  DEFAULT   ABS /buildbot/tmp/crtbrand-440a44.o
    28: 0000000000000000     0 FILE    LOCAL  DEFAULT   ABS crtbegin_so.c
    37: 0000000000000000     0 FILE    LOCAL  DEFAULT   ABS foo.cpp
    41: 0000000000000000     0 FILE    LOCAL  DEFAULT   ABS 

$ $TOOLCHAIN/bin/aarch64-linux-android-objcopy --strip-debug libfoo.so  libfoo-stripped.so && readelf -s libfoo-stripped.so  | grep FILE
<nothing>

[biasmv]

Thanks aarch64-linux-android-objcopy indeed removes the FILE symbols. Is this an expected difference between the two objcopy implementations? Or is it worth submitting a bug to llvm-objcopy?

[enh-google]

yeah, given that the manual mentions a --keep-file-symbols option, i'm assuming that this is indeed a bug :-)

@pirama-arumuga-nainar might know more because i think he was involved in some of the objcopy issues we had switching the OS itself over to llvm-objcopy... maybe this is already fixed?

[pirama-arumuga-nainar]

@kongy has the most background on this. We did fix some llvm-objcopy in later AOSP clang versions.

[enh-google]

@kongy uploaded https://reviews.llvm.org/D76675 to fix this upstream...

[DanAlbert]

It seems this affects only objcopy and not strip. Since we don't use llvm-objcopy in ndk-build or our CMake toolchain and using the LLVM flavors of the tools is only a recommendation in r21, I'm leaning toward saying this can wait until r22.

That said, if @stephenhines and co think this is trivial to fix in r21 we might as well since it's the LTS people will be on for a while and we're already working on a release of that. WDYT?

[stephenhines]

I think this is fine for r22. We haven't switched to the LLVM binutils in r21 LTS (and there would be a workaround for this), so this doesn't really belong there.

[biasmv]

Thanks for getting this fixed so quickly! What's the procedure here, do you want to keep the ticket open as long as the change to LLVM is still pending?

[DanAlbert]

Yeah, we'll keep this open until we've merged it into the NDK. Once the fix is available in our master branch we'll close it.

[stephenhines]

Yi, can you follow up on that upstream patch to ensure it makes it in? I'd like to be able to get this for R22. We can cherry-pick as necessary after Yabin's update too.