删除 C++-STL/Boost 调试符号(...或者不创建它们)

发布于 2024-07-05 11:23:28 字数 626 浏览 2 评论 0原文

Linux/Gcc/LD - 工具链。

我想从库和可执行文件中删除 STL/Boost 调试符号,原因有两个:

  1. 对于大型程序,链接变得非常慢
  2. 调试跳转到 stl/boost 代码,这很烦人

对于 1. 增量链接将是一个很大的改进,但据我所知ld 不支持增量链接。 1999 年 dr.dobb 的日记中有一个解决方法“伪增量链接”(不再在网络中,而是在 archive.org (想法是将所有内容放入动态库中,并将所有更新的目标文件放入加载的第二个库中首先)但这并不是一个真正的通用解决方案。

对于 2. 这里有一个脚本这里,但是a)它对我不起作用(它没有删除符号),b)它非常慢,因为它在管道末端工作,而尽早删除符号会更有效。

显然,其他调试符号应该保留在原处。

Linux/Gcc/LD - Toolchain.

I would like to remove STL/Boost debug symbols from libraries and executable, for two reasons:

  1. Linking gets very slow for big programs
  2. Debugging jumps into stl/boost code, which is annoying

For 1. incremental linking would be a big improvement, but AFAIK ld does not support incremental linking. There is a workaround "pseudo incremental linking" in an 1999 dr.dobb's journal (not in the web any more, but at archive.org (the idea is to put everything in a dynamic library and all updated object files in an second one that is loaded first) but this is not really a general solution.

For 2. there is a script here, but a) it did not work for me (it did not remove symbols), b) it is very slow as it works at the end of the pipe, while it would be more efficient to remove the symbols earlier.

Obviously, the other debug symbols should stay in place.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

恍梦境° 2024-07-12 11:23:28

据我所知,在 gcc 中没有真正的选择可以做你想做的事情。 主要问题是您想要删除调试符号的所有代码都在标头中定义。

否则,可以单独构建一个库,剥离该库,然后与剥离的版本链接。

但据我所知,在 gcc 中,仅从编译单元的某些部分获取调试符号,而构建和链接(为了您所需的链接时间加速)是不可能的。

As far as I know there's no real option to do what you want in gcc. The main problem being that all the code you want to strip debug symbols for is defined in headers.

Otherwhise it would be possible to build a library separatly, strip that, and link with the stripped version.

But only getting debug symbols from certain parts of a compilation unit, while building and linking (for your desired link time speedup) is not possible in gcc as far as I know.

懵少女 2024-07-12 11:23:28

GNU strip 接受 --strip-symbols= 的正则表达式参数
STL 和 boost 符号由于它们所在的命名空间而被名称破坏。目前我没有方便的 GCC binutils,但只需查看用于命名空间的名称破坏并为“来自命名空间 X 的符号”构造正则表达式' 并将其传递给 --strip-symbols=

GNU strip accepts regex arguments to --strip-symbols=
The STL and boost symbols are name-mangled because of the namespaces they're in. I don't have GCC binutils handy at this moment, but just peek at the name mangling used for namespaces and construct the regex for 'symbols from namespace X' and pass this to --strip-symbols=

叹梦 2024-07-12 11:23:28

您可能想使用条带。
strip --strip-unneeded --strip-debug libfoo.so

为什么不首先构建而不进行调试呢?

You may want to use strip.
strip --strip-unneeded --strip-debug libfoo.so

Why don't you just build without debugging in the first place though?

清风不识月 2024-07-12 11:23:28

这个答案提供了我需要使 MSalters 的答案能够删除 STL 符号的一些细节。

STL 符号名称被破坏。 诀窍是找到涵盖这些名称的正则表达式。 我用 GNU 的 Binutils 查找了这些符号:

> nm --debug-syms <objectfile>

我基本上搜索了 STL 函数,例如 resize。 如果这很困难,则使用以下命令时输出将变得可读:

> nm --debug-syms --demangle <objectfile>

查找包含 STL 函数调用的行号,然后使用第一个提供的命令在同一行号上查找其损坏的名称。 这让我看到所有 STL 符号名称都以 _ZNSt[0-9]+_ZSt[0-9]+ 等开头。

允许 GNU Strip 删除我使用的这些符号:

> strip --wildcard              \
    --strip-symbol='_ZNKSt*'    \
    --strip-symbol='_ZNSt*'     \
    --strip-symbol='_ZSt*'      \
    --strip-symbol='_ZNSa*'     \
    <objectfile>

我直接在编译/链接的二进制文件上使用这些命令。 我通过比较删除前后的 nm 输出来验证这些符号的删除(我将输出写入文件并使用 vimdiff)。 --wildcard 选项允许使用正则表达式。 虽然我希望 [0-9]* 表示 0 到无限数量的数字,但这里它实际上意味着 1 个数字后跟无限数量的任何东西(直到行尾)。

如果您希望不进入 STL 代码,可以通过 gdb 的 skip file 命令来实现,如 这里

希望能帮助到你

This answer provides some specifics that I needed to make MSalters' answer work for removing STL symbols.

The STL symbol names are mangled. The trick is to find a regular expression that covers these names. I looked these symbols up with GNU's Binutils:

> nm --debug-syms <objectfile>

I basically searched on STL functions, like resize. If this is difficult, the output becomes readable when using the following command:

> nm --debug-syms --demangle <objectfile>

Look up a line number containing an STL function call, then look up it's mangled name on that same line number using the first provided command. This allowed me to see that all STL symbol names began with _ZNSt[0-9]+ or _ZSt[0-9]+, etc.

To allow GNU Strip to remove these symbols I used:

> strip --wildcard              \
    --strip-symbol='_ZNKSt*'    \
    --strip-symbol='_ZNSt*'     \
    --strip-symbol='_ZSt*'      \
    --strip-symbol='_ZNSa*'     \
    <objectfile>

I used these commands directly on the compiled/linked binary. I verified the removal of these symbols by comparing the output of nm before and after the removal (I wrote the output to files and used vimdiff). The --wildcard option allows the use of regular expressions. Although I would expect [0-9]* to mean 0 to an infinite amount of numbers, here it actually means 1 number followed by an infinite amount of anything (until the end of the line).

If you are looking to not step into STL code this can be achieved by gdb's skip file command, as done here.

Hope it helps

℡寂寞咖啡 2024-07-12 11:23:28

您可能不想从共享库中删除调试符号,因为您可能在某些时候需要它。

如果您使用 GDB 或 DDD 进行调试,您也许可以从源路径中删除 Boost 源文件,这样它就无法跟踪到函数。 (或者只是不跟踪它们,而是跟踪!)

您可以删除使用调试符号编译程序的选项,这将加快链接时间。

与您链接到的脚本一样,您可以查阅 strip 程序(“man strip”)来删除所有或某些符号。

You probably don't want to strip the debug symbols from the shared libraries, as you may need that at some point.

If you are using GDB or DDD to debug, you may be able to get away with removing the Boost source files from the Source Path so it can't trace into the functions. (Or just don't trace into them, trace over!)

You can remove the option to compile the program with debug symbols, which will speed the link time.

Like the script you link to, you can consult the strip program ("man strip") to remove all or certain symbols.

沙沙粒小 2024-07-12 11:23:28

您使用哪个编译器? 例如,如果我正确理解你的问题,那么这在 MS Visual Studio 中是一件小事。

Which compiler are you using? For example, if I understand your question correctly, this is a trivial matter in MS Visual Studio.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文