You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With -C debuginfo=2, the debug info emitted on Linux would include two “pub” sections, .debug_pubnames and .debug_pubtypes. These two sections are for faster name lookup in debugger, but were designed with flaws, and has been superceded by a new debug section in DWARF version 5.
While they have been there since DWARF version 2, debuggers seldom make use of them. Clang doesn't emit it by default, so does GCC. GCC/GDB even have their own “enhanced” format of these pub sections, i.e. .debug_gnu_pubnames and .debug_gnu_pubtypes. These sections are useful only when .gdb_index is present, and that requires an explicit flag passed in to linker invocations.
Let me quote what other people have said (in an random order):
“The pubnames and pubtypes data described in Section 6.1 are much larger than needed, since they contain redundant information, and the are missing other information, such as local symbol names.” — https://dwarfstd.org/issues/140817.1.html
“The main reason for this is we don't trust the “.debug_pubnames” section as it it useless for debuggers. Why? .debug_pubnames is an accelerator table that shows only functions that are externally visible in a program. This means all static functions and data, and any functions that are hidden in a shared library won't be in the list.” — https://discourse.llvm.org/t/some-basic-lldb-usage-questions/16356/2
“The .debug_pubnames section was always intended as a comprehensive list of symbols that gdb could use for quick lookup, but bugs in gcc have so far prevented gdb from using this section for its intended purpose…” — https://gcc.gnu.org/wiki/DebugFission
“We propose that GCC simply stop emitting .debug_pubnames and .debug_pubtypes, as experience has shown that they are not very useful. (In fact, on Linux GCC did not even generate .debug_pubtypes until 2009, and no one ever complained.)” — https://gcc.gnu.org/wiki/DebugGNUIndexSection
“Okay I see they are rarely useful, but why we do want to remove them?”
Because they are huge!
On x86_64-unknown-linux-gnu with rustc 1.76.0-nightly (dd430bc8c 2023-11-14). For example, cargo built in debug mode has 86 MiB of .debug_pubtypes section and 45 MiB of .debug_pubnames. They take 31% out of the entire 413 MiB for the cargo binary.
click to see size of each section headers of cargo
That is, in general. If we can remove both of these sections, the final binary size can be cut off around ~30%.
If we can remove both of the sections, conceptually the memory usage would drop a lot during linking stage, and we can save the disk usage as well.
People has suffered from OOM-killed in linking stage and I've traced down. It is usually the output binary size exceeding available RAM.
There is an issue in Rust-for-Linux calling out Rust binaries are huge and looking forward to some solutions. An existing issue in rust-lang/rust: rust-lang/rust#48762.
Change Proposal
We should turn generation of these sections off since they are not useful.
User-facing impact
If any debuggers were using these sections, initial loading of debuginfo might become slower but there should be no functional regressions (debuggers in general do not use these tables so there should not be any such performance degradation, but that is the most likely conceivable negative outcome).
It is possible that other tools use these sections for various purposes, but we do not know of any such tools at this time.
Alternative
Stabilize -Zdwarf-version, or make DWARF version 5 the default on certain platform (presumably on Linux). Pub sections are replaced in DWARFv5 with a better, more compact and useful .debug_names section.
A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
Finding a “second” suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
Proposal
Background
With
-C debuginfo=2, the debug info emitted on Linux would include two “pub” sections,.debug_pubnamesand.debug_pubtypes. These two sections are for faster name lookup in debugger, but were designed with flaws, and has been superceded by a new debug section in DWARF version 5.While they have been there since DWARF version 2, debuggers seldom make use of them. Clang doesn't emit it by default, so does GCC. GCC/GDB even have their own “enhanced” format of these pub sections, i.e.
.debug_gnu_pubnamesand.debug_gnu_pubtypes. These sections are useful only when.gdb_indexis present, and that requires an explicit flag passed in to linker invocations.Let me quote what other people have said (in an random order):
“Okay I see they are rarely useful, but why we do want to remove them?”
Because they are huge!
On
x86_64-unknown-linux-gnuwithrustc 1.76.0-nightly (dd430bc8c 2023-11-14). For example,cargobuilt in debug mode has 86 MiB of.debug_pubtypessection and 45 MiB of.debug_pubnames. They take 31% out of the entire 413 MiB for thecargobinary.click to see size of each section headers of cargo
with pub sections:
without pub sections:
Another example is a popular CLI tool ripgrep. It is 63 MiB in total in debug mode build, and pub sections made up 27% of the size, which is 17 MiB.
click to see size of each section headers of ripgrep
with pub sections
without pub sections
That is, in general. If we can remove both of these sections, the final binary size can be cut off around ~30%.
If we can remove both of the sections, conceptually the memory usage would drop a lot during linking stage, and we can save the disk usage as well.
People has suffered from OOM-killed in linking stage and I've traced down. It is usually the output binary size exceeding available RAM.
There is an issue in Rust-for-Linux calling out Rust binaries are huge and looking forward to some solutions. An existing issue in rust-lang/rust: rust-lang/rust#48762.
Change Proposal
We should turn generation of these sections off since they are not useful.
User-facing impact
If any debuggers were using these sections, initial loading of debuginfo might become slower but there should be no functional regressions (debuggers in general do not use these tables so there should not be any such performance degradation, but that is the most likely conceivable negative outcome).
It is possible that other tools use these sections for various purposes, but we do not know of any such tools at this time.
Alternative
Stabilize
-Zdwarf-version, or make DWARF version 5 the default on certain platform (presumably on Linux). Pub sections are replaced in DWARFv5 with a better, more compact and useful.debug_namessection.Mentors or Reviewers
@wesleywiser is willing to review
Process
The main points of the Major Change Process are as follows:
@rustbot second.-C flag, then full team check-off is required.@rfcbot fcp mergeon either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.