即使在 CMake 中构建 Release 也能在最终 SO 文件中获取调试符号答案

【问题标题】：Getting debug symbols in final SO file even when building Release in CMake即使在 CMake 中构建 Release 也能在最终 SO 文件中获取调试符号
【发布时间】：2015-07-15 16:01:14
【问题描述】：

我正在使用 CMake（生成器是 ninja）使用 NDK 工具链（g++ 4.9）构建共享库。下面是我使用 ninja 构建时在库中构建单个 CPP 文件的详细输出：

[34/164] /usr/local/bin/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ -DANDROID -DBOOST_ALL_NO_LIB -fexceptions -frtti -fpic -Wno-psabi --sysroot=/usr/local/bin/android-ndk/platforms/android-15/arch-arm -funwind-tables -finline-limit=64 -fsigned-char -no-canonical -prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -fdata-sections -ffunction-sections -Wa,--noexecstack -mthumb -fomit-frame-pointer -fno-strict-aliasing -O3 -DNDEBUG -isystem /usr/local/bin/android-ndk/platforms/android-15/arch-arm/usr/include -isystem /usr/local/bin/android-ndk/sources/cxx-stl/gnu-libstdc++ /4.9/include -isystem /usr/local/bin/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include -isystem /usr/local/bin/android-ndk/sources /cxx-stl/gnu-libstdc++/4.9/include/backward -I/usr/local/bin/android-ndk/sources/android/cpufeatures -I/usr/local/bin/android-ndk/sources/android/native_app_glue -ICore/Artifacts/Android -IApplications/Su rvey/源-ICore/UI/。 -ICore/UI/Source -ICore/ThirdParty/PowerVR/sdk/Include -ICore/ThirdParty/PowerVR/tools/include -ICore/ThirdParty/PowerVR/tools/include/OGLES2 -ICore/ThirdParty/boost/include -ICore/ThirdParty /openssl/include -ICore/ThirdParty/sqlite/include -ICore/WebServices/Source -std=gnu++14 -MMD -MT Applications/Survey/CMakeFiles/Survey.dir/Source/View/RadioGroup.cpp.o -MF Applications/Survey/CMakeFiles/Survey.dir/Source/View/RadioGroup.cpp.o.d -o Applications/Survey/CMakeFiles/Survey.dir/Source/View/RadioGroup.cpp.o -c Applications/Survey/Source/View/ RadioGroup.cpp

请注意，我在生成时指定了-DCMAKE_BUILD_TYPE=Release。

-g 选项在命令行调用中不存在，但最终二进制文件为 19MB：

-rwxrwxr-x 1 bamboo bamboo 19173588 Jul 15 10:30 libzApp.so*

我在上面运行了size 以确定是什么让它如此庞大，但我得到了这个：

$ size libzApp.so
   text    data     bss     dec     hex filename
7097019  201268   53488 7351775  702ddf libzApp.so

这仅占 7mb 的数据。所以我运行了这个：

$ objdump --debugging libzApp.so | head -25

libzApp.so:     file format elf32-little

Contents of the .debug_abbrev section:

  Number TAG (0x0)
   1      DW_TAG_compile_unit    [has children]
    DW_AT_producer     DW_FORM_strp
    DW_AT_language     DW_FORM_data1
    DW_AT_name         DW_FORM_strp
    DW_AT_comp_dir     DW_FORM_strp
    DW_AT_low_pc       DW_FORM_addr
    DW_AT_entry_pc     DW_FORM_addr
    DW_AT_ranges       DW_FORM_data4
    DW_AT_stmt_list    DW_FORM_data4
    DW_AT value: 0     DW_FORM value: 0
   2      DW_TAG_typedef    [no children]
    DW_AT_name         DW_FORM_strp
    DW_AT_decl_file    DW_FORM_data1
    DW_AT_decl_line    DW_FORM_data1
    DW_AT_type         DW_FORM_ref4
    DW_AT value: 0     DW_FORM value: 0
   3      DW_TAG_base_type    [no children]
    DW_AT_byte_size    DW_FORM_data1
    DW_AT_encoding     DW_FORM_data1

我认为这几乎证实了它具有调试符号。谁能帮我理解为什么 .so 这么大？假设是因为调试符号，那么命令行调用会导致这种情况吗？

编辑

正如 cmets 部分所建议的，在 SO 文件上运行 strip 肯定会使其大小降至预期值（基本上是我们从 size 命令的结果中看到的）。但是，当我明确告诉 GCC 不构建调试符号时，为什么要在共享对象中构建调试符号呢？我在这里遗漏了什么吗？

【问题讨论】：

你能确认strip之后的尺寸还是一样的吗？
是的，strip 将其缩小到预期大小：$ ll libzApp.so -- -rwxrwxr-x 1 bamboo bamboo 7301876 Jul 15 11:18 libzApp.so*
这能解决你的问题吗？您也可以尝试删除`-DNDEBUG`吗？
为什么我需要strip 符号？如果我没有告诉 gcc 构建调试符号，为什么它们首先存在？我会尝试删除 NDEBUG 并让你知道它是怎么回事，但我认为我们可能有预处理器条件依赖于这个设置。
实际上我无法删除 NDEBUG，这是在我从这里提取的 android 工具链文件中定义的：github.com/taka-no-me/android-cmake

标签： android c++ gcc android-ndk g++

【解决方案1】：

我可以建议你使用strip删除调试信息，例如：

strip libzApp.so

这样做还不错，例如，Qt 的构建系统 qmake 总是在生成的 Makefile 的 install 目标中这样做。

默认情况下，编译器总是将重定位信息和符号表添加到二进制文件中。它还添加了许多其他可能被删除的信息（请参阅下面的答案链接）。

您也可以在编译器中使用-s 参数：

g++ -s ...

根据文档：

-s:

Remove all symbol table and relocation information from the executable.

这个标志应该和strip 一样工作。这里也是some similiar answer on stackoverflow。

【讨论】：