Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strip useless debug sections from binaries, to make them smaller. #2514

Closed
wants to merge 2 commits into from

Conversation

hlinnaka
Copy link
Contributor

The rust compiler or linker (I'm not sure which) emits .debug_pubnames and .debug_pubtypes sections in the binaries. They are supposed to speed up launching a debugger, but they're obsolete. They've been superseded by .debug_names section in more recent DWARF spec and debuggers, and gdb and lldb just ignores them.

I could not find any way to prevent rustc / ldb / mold from emitting these sections in the first place. So this commit adds a hack to strip them off afterwards. This makes the binaries about 30% smaller, for no apparent downside.

@hlinnaka
Copy link
Contributor Author

The strip-step takes about 90 seconds, which is more than I hoped. Might still be worthwhile. Or maybe do this only for the larger binaries or some other such compromise.

Copy link
Contributor

@SomeoneToIgnore SomeoneToIgnore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I like the lesser size despite the drastic time increase, and I think we should add the same for the Docker builds: 1.5mins added to already existing ~30 mins is not huge, but we allow to download ~30% less data, which happens more frequently than builds.

I've also noticed that most of the time is consumed by the last command:
find target -executable -type f -links +1 ! -name "*.lock" | xargs -IPATH objcopy -R .debug_pubnames -R .debug_pubtypes -p PATH

I wonder, how much do we remove without it, maybe it's already enough.

Copy link
Member

@sharnoff sharnoff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same opinion as @SomeoneToIgnore

@hlinnaka
Copy link
Contributor Author

hlinnaka commented Nov 5, 2022

I wasn't happy with the added 1.5 minutes, so I spent a little more time on this. I replaced the "find | xargs" commands with a little python script. It understands hard links and knows not to invoke two objcopy's on the same hardlinked file, which allows more processes to run in parallel. This runs in 30 s on my laptop now, let's see how fast it is in the CI.

@SomeoneToIgnore
Copy link
Contributor

SomeoneToIgnore commented Nov 5, 2022

1m 46s, most of the time seems to be spent on async-trait? We could try and filter that out (yet apparently we have to rethink some approaches to traits instead)

image

The rust compiler or linker (I'm not sure which) emits .debug_pubnames
and .debug_pubtypes sections in the binaries. They are supposed to speed
up launching a debugger, but they're obsolete. They've been superseded
by .debug_names section in more recent DWARF spec and debuggers, and
gdb and lldb just ignores them.

I could not find any way to prevent rustc / ldb / mold from emitting
these sections in the first place. So this commit adds a hack to strip
them off afterwards. This makes the binaries about 30% smaller, with
the downside of adding about 30 s to the build time in CI. That seems
like a good tradeoff, as smaller binaries can speed up other steps.
@SomeoneToIgnore
Copy link
Contributor

Related: #2803

@LizardWizzard
Copy link
Contributor

As discussed moving to draft

@LizardWizzard LizardWizzard marked this pull request as draft March 21, 2023 15:53
@hlinnaka
Copy link
Contributor Author

There's a new proposal on rustc to stop emitting these: rust-lang/compiler-team#688

@hlinnaka
Copy link
Contributor Author

This was fixed in rustc 1.76.0, it no longer generates the useless .debug_pubnames and .debug_pubtypes sections (see rust-lang/rust#48762). Closing.

(Our binaries are still huge, but for different reasons)

@hlinnaka hlinnaka closed this Apr 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants