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.

Sign up for GitHub

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

Jump to bottom

Stop emitting .debug_pubnames and .debug_pubtypes into Linux object files and binaries #48762

Closed
rocallahan opened this issue Mar 6, 2018 · 7 comments · Fixed by #117962
Closed

Stop emitting .debug_pubnames and .debug_pubtypes into Linux object files and binaries #48762

rocallahan opened this issue Mar 6, 2018 · 7 comments · Fixed by #117962
Assignees
@pnkfelix @wesleywiser
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-enhancement Category: An issue proposing an enhancement or a PR with one. I-compiletime Issue: Problems and improvements with respect to compile times. I-heavy Issue: Problems and improvements with respect to binary size of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@rocallahan
Copy link

As far as I can tell, nothing uses these. They bloat executables and make linking more expensive.

At least stop emitting them for debuginfo=1.
@pietroalbini pietroalbini added O-linux Operating system: Linux A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 6, 2018
@sfackler sfackler removed the O-linux Operating system: Linux label Mar 7, 2018
@sfackler
Copy link
Member

sfackler commented Mar 7, 2018

It seems like gcc and clang don't emit these anymore, so it'd probably make sense for us to skip them as well.

@rocallahan rocallahan mentioned this issue Mar 19, 2018
Open
@tromey
Copy link
Contributor

tromey commented Nov 15, 2018

I have a patch for this but I'm still looking at how to write a test for it.

@tromey
Copy link
Contributor

tromey commented Nov 16, 2018

I learned on #llvm that these sections may be read by lld to create a .gdb_index section. So perhaps they are desirable after all. I'll look into lld to see.

@tromey
Copy link
Contributor

tromey commented Nov 16, 2018

.debug_pubnames and .debug_pubtypes are indeed read by lld when --gdb-index is given. This doesn't appear to be the default. This emits an index that speeds up gdb symbol reading. So, it seems that Linux is the platform where these sections might be useful. However, since it requires a linker flag, perhaps the thing to do is just drop this everywhere.

@DenialAdams
Copy link

DenialAdams commented Nov 16, 2018 •
edited
Loading

.debug_pubnames and .debug_pubtypes are indeed read by lld when --gdb-index is given. This doesn't appear to be the default. This emits an index that speeds up gdb symbol reading. So, it seems that Linux is the platform where these sections might be useful. However, since it requires a linker flag, perhaps the thing to do is just drop this everywhere.

It seems like we could put emitting them behind a rustc flag by default, but add a cargo option that causes them to be emitted and turns the linker flag on?

@tromey
Copy link
Contributor

tromey commented Nov 19, 2018

It seems like we could skip emitting them by default, but add a cargo option that causes them to be emitted and turns the linker flag on?

Yeah, that could be done. I have other priorities, though, so I'm going to drop this for now. I can share my rustc patch if anybody wants to pick it up.

tromey added a commit to tromey/rust that referenced this issue Jan 15, 2019
@tromey
Do not emit .debug_pubnames on Linux
47b2154 
Nothing uses .debug_pubnames or .debug_pubtypes on Linux, so omit
these sections there.

Closes rust-lang#48762
@khuey
Copy link
Contributor

khuey commented Mar 20, 2019

What blocks landing this?

@jonas-schievink jonas-schievink added I-compiletime Issue: Problems and improvements with respect to compile times. I-heavy Issue: Problems and improvements with respect to binary size of generated code. labels Apr 18, 2020
@pnkfelix pnkfelix self-assigned this Apr 5, 2021
@csmoe csmoe mentioned this issue Feb 20, 2022
Closed
@kazcw kazcw mentioned this issue May 27, 2022
Merged
4 tasks
@fpoli fpoli mentioned this issue Sep 29, 2022
Merged
@wesleywiser wesleywiser self-assigned this Aug 21, 2023
This was referenced Nov 3, 2023
Open
Open
This was referenced Nov 16, 2023
Merged
Closed
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 17, 2023
@bors
Auto merge of rust-lang#117962 - weihanglo:debug-name-table, r=<try>
5432eb3 
[EXPERIMENT] fix: stop `emitting .debug_pubnames` and `.debug_pubtypes`

### DO NOT MERGE

---

A continuation of rust-lang#94181.
Fixes rust-lang#48762
MCP can be found in <rust-lang/compiler-team#688>.

`.debug_pubnames` and `.debug_pubtypes` are poorly designed and people
seldom use them. However, they take a considerable portion of size in
the final binary. This tells LLVM stop emitting those sections on
DWARFv4 or lower. DWARFv5 use `.debug_names` which is more concise
in size and performant for name lookup.
bors added a commit to rust-lang-ci/rust that referenced this issue Dec 11, 2023
@bors
Auto merge of rust-lang#117962 - weihanglo:debug-name-table, r=<try>
7db8714 
fix: stop `emitting .debug_pubnames` and `.debug_pubtypes`

A continuation of rust-lang#94181.
Fixes rust-lang#48762
MCP can be found in <rust-lang/compiler-team#688>.

`.debug_pubnames` and `.debug_pubtypes` are poorly designed and people
seldom use them. However, they take a considerable portion of size in
the final binary. This tells LLVM stop emitting those sections on
DWARFv4 or lower. DWARFv5 use `.debug_names` which is more concise
in size and performant for name lookup.

Some other no-really-useful personal notes:

<details><summary>Details</summary>
<p>

## Pepole saying they are not useful

* rust-lang#48762
* https://rust-lang.zulipchat.com/#narrow/stream/317568-t-compiler.2Fwg-debugging/topic/investigating.20debuginfo.20size/near/342713604
* `DwarfCompileUnit::hasDwarfPubSections()` — https://github.com/llvm/llvm-project/blob/f633f325a1b808d33ca9653ed373353549ddcde6/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp#L1477-L1494
* clang default to no debug name table when no option provided — https://github.com/llvm/llvm-project/blob/f633f325a1b808d33ca9653ed373353549ddcde6/clang/lib/Frontend/CompilerInvocation.cpp#L1819-L1824
* GCC explicitly says GDB doesn't use pub sections (`TARGET_WANT_DEBUG_PUB_SECTIONS` only be true on Darwin) — https://github.com/gcc-mirror/gcc/blob/5d2a360f0a541646abb11efdbabc33c6a04de7ee/gcc/target.def#L6985-L6990 and https://github.com/bminor/binutils-gdb/blob/319b460545dc79280e2904dcc280057cf71fb753/gold/dwarf_reader.h#L424-L427
* Probably the only place that makes use of pub section in lldb — https://github.com/llvm/llvm-project/blob/725115d7bba2faf3d0c21442f4661dea77b8a77c/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L2117-L2135

* "The -gsplit-dwarf option requires -ggnu-pubnames." — https://github.com/gcc-mirror/gcc/blob/5d2a360f0a541646abb11efdbabc33c6a04de7ee/gcc/opts.cc#L1205

* LLVM: Always emit `.debug_names` with dwarf 5 for Apple platforms — https://reviews.llvm.org/D118754

</p>
</details>
@bors bors closed this as completed in e2a3c9b Dec 12, 2023
@hlinnaka hlinnaka mentioned this issue Apr 21, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pnkfelix pnkfelix

@wesleywiser wesleywiser

Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-enhancement Category: An issue proposing an enhancement or a PR with one. I-compiletime Issue: Problems and improvements with respect to compile times. I-heavy Issue: Problems and improvements with respect to binary size of generated code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
9 participants
@pnkfelix @rocallahan @khuey @wesleywiser @sfackler @tromey @jonas-schievink @DenialAdams @pietroalbini