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

LTO build emits debug symbols even with debug disabled #43392

Closed
joshtriplett opened this issue Jul 21, 2017 · 4 comments
Closed

LTO build emits debug symbols even with debug disabled #43392

joshtriplett opened this issue Jul 21, 2017 · 4 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug.

Comments

@joshtriplett
Copy link
Member

joshtriplett commented Jul 21, 2017

Even when building with opt-level=3 and debug=false, rustc emits binaries with debug symbols.

I was experimenting with building a binary using no_std. My Cargo.toml looked like this:

[package]
name = "embedtest"
version = "0.1.0"
authors = ["Josh Triplett <[email protected]>"]

[profile.release]
panic = "abort"
lto = true

[dependencies]
libc = { version = "0.2", default-features = false }

main.rs:

#![no_std]
#![feature(lang_items, start)]

extern crate libc;

#[lang="panic_fmt"]
extern fn panic_fmt(_: ::core::fmt::Arguments, _: &'static str, _: u32) -> ! {
    loop {}
}

#[start]
fn start(_: isize, _: *const *const u8) -> isize {
    0
}

When built, this resulted in a 28408-byte binary. Checking with objdump showed the majority of that space in debug sections:

 25 .debug_pubnames 0000085b  0000000000000000  0000000000000000  0000102d  2**0
                  CONTENTS, READONLY, DEBUGGING
 26 .debug_info   000017d4  0000000000000000  0000000000000000  00001888  2**0
                  CONTENTS, READONLY, DEBUGGING
 27 .debug_abbrev 0000010a  0000000000000000  0000000000000000  0000305c  2**0
                  CONTENTS, READONLY, DEBUGGING
 28 .debug_line   000001bb  0000000000000000  0000000000000000  00003166  2**0
                  CONTENTS, READONLY, DEBUGGING
 29 .debug_frame  00000038  0000000000000000  0000000000000000  00003328  2**3
                  CONTENTS, READONLY, DEBUGGING
 30 .debug_str    000026c5  0000000000000000  0000000000000000  00003360  2**0
                  CONTENTS, READONLY, DEBUGGING
 31 .debug_macinfo 00000001  0000000000000000  0000000000000000  00005a25  2**0
                  CONTENTS, READONLY, DEBUGGING
 32 .debug_pubtypes 000001f2  0000000000000000  0000000000000000  00005a26  2**0
                  CONTENTS, READONLY, DEBUGGING

strip removed these (along with the symbol tables) and resulted in a 6040-byte binary.

I can reproduce this with nightly 1.20 from commit ae98ebf (for the example above), stable 1.17 (with a std-based hello world example), and stable 1.18 (likewise).

@Mark-Simulacrum Mark-Simulacrum added A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug. labels Jul 26, 2017
@jcbritobr
Copy link

Hi guys, fix this please. Is very annoying compile release and have to strip executable for production every time a new compilation.

@nhynes
Copy link
Contributor

nhynes commented Oct 1, 2019

I'm getting the same on 1.39-nightly. It makes for deceptively large wasm release builds (but at least there's great tooling for shrinking them :)

@bjorn3
Copy link
Member

bjorn3 commented May 15, 2022

You can now use

[profile.release]
strip = "debuginfo"

in your Cargo.toml to strip debuginfo while linking. You can also use strip = "symbols" to also strip symbol names.

@joshtriplett
Copy link
Member Author

Yeah, strip solves the issue of the symbols from the standard library, and that's the best solution we have available at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

5 participants