Skip to content

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

Closed

Description

@rocallahan

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.

Activity

  1. added
    O-linuxOperating system: Linux
    A-debuginfoArea: Debugging information in compiled programs (DWARF, PDB, etc.)
    C-enhancementCategory: An issue proposing an enhancement or a PR with one.
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Mar 6, 2018
  2. sfackler commented on Mar 7, 2018

    @sfackler
    Member

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

  3. tromey commented on Nov 15, 2018

    @tromey
    Contributor

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

  4. tromey commented on Nov 16, 2018

    @tromey
    Contributor

    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.

  5. tromey commented on Nov 16, 2018

    @tromey
    Contributor

    .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.

  6. DenialAdams commented on Nov 16, 2018

    @DenialAdams

    .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?

  7. tromey commented on Nov 19, 2018

    @tromey
    Contributor

    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.

  8. added a commit that references this issue on Jan 15, 2019
    47b2154
  9. khuey commented on Mar 20, 2019

    @khuey
    Contributor

    What blocks landing this?

  10. added
    I-compiletimeIssue: Problems and improvements with respect to compile times.
    I-heavyIssue: Problems and improvements with respect to binary size of generated code.
    on Apr 18, 2020
  11. self-assigned this
    on Apr 5, 2021
  12. self-assigned this
    on Aug 21, 2023
  13. added a commit that references this issue on Nov 17, 2023
    5432eb3
  14. added 2 commits that reference this issue on Dec 11, 2023
    7db8714
    e2a3c9b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

A-debuginfoArea: Debugging information in compiled programs (DWARF, PDB, etc.)C-enhancementCategory: An issue proposing an enhancement or a PR with one.I-compiletimeIssue: Problems and improvements with respect to compile times.I-heavyIssue: Problems and improvements with respect to binary size of generated code.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions