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

Allow backtrace information to be optional #1417

Open
Earlz opened this issue Dec 18, 2015 · 15 comments
Open

Allow backtrace information to be optional #1417

Earlz opened this issue Dec 18, 2015 · 15 comments
Labels
T-compiler Relevant to the compiler team, which will review and decide on the RFC. T-dev-tools Relevant to the development tools team, which will review and decide on the RFC.

Comments

@Earlz
Copy link

Earlz commented Dec 18, 2015

There appears to be no way to disable backtrace information embedding into a program. There are some cases where bundling filenames and other information needed for backtraces is not desired. Two cases I can think of immediately is wanting to provide as little information as possible in proprietary products. The other case is where you need the final binary to be as small as possible.

There is an old set of patches that added this that seem to be stale now.. Maybe they can be used as a starting point? https://github.com/japaric/std-with-cargo And there was also some discussion about this on the rust-internals IRC, but nothing seemed to come out of it: https://botbot.me/mozilla/rust-internals/2015-08-20/?msg=47709853&page=4

@ticki
Copy link
Contributor

ticki commented Dec 21, 2015

👍 Always bothered me.

@eddyb
Copy link
Member

eddyb commented Dec 23, 2015

What backtrace information? We use the symbol names or debug info, just like C and C++.
If you're compiling an executable in release mode, all you have to do is strip symbols (the same as a proprietary C or C++ project would have to do).

@ticki
Copy link
Contributor

ticki commented Dec 23, 2015

What backtrace information? We use the symbol names or debug info, just like C and C++.
If you're compiling an executable in release mode, all you have to do is strip symbols (the same as a proprietary C or C++ project would have to do).

It would make sense to provide a way to compile it without the symbol names & debug info. Futhermore, panics will show file name and line number (though this is not rustc, but libstd).

@eddyb
Copy link
Member

eddyb commented Dec 23, 2015

@ticki To compile without debug info: remove -g. Cargo.toml has a way to turn it off even for debug mode, while release mode doesn't come with debug info.

Compiling without symbol names doesn't make sense: they're certainly mandatory for libraries, and executables cannot drop symbol names until linking has finished.

EDIT: gcc appears to have an -s option for stripping the symbol names after linking. I guess we could add that?

@ticki
Copy link
Contributor

ticki commented Dec 23, 2015

To compile without debug info: remove -g. Cargo.toml has a way to turn it off even for debug mode, while release mode doesn't come with debug info.

That'll still show line number and file name when panicking.

gcc appears to have an -s option for stripping the symbol names after linking. I guess we could add that?

Yeah, that was what I thought of. It -s often comes very handy.

@eddyb
Copy link
Member

eddyb commented Dec 23, 2015

Panics are not "backtrace information", they're file!() and line!() macros - having a way to obscure those would be useful, but you'd have to recompile the entire libstd in that mode if you want to get rid of all of them (they're just string literals as far as the post-expansion compiler is concerned).

@eddyb
Copy link
Member

eddyb commented Dec 23, 2015

Also, if you want a solution now for the "strip symbols part", you can use strip instead of having it built-in like gcc -s.

@ticki
Copy link
Contributor

ticki commented Dec 23, 2015

Panics are not "backtrace information", they're file!() and line!() macros - having a way to obscure those would be useful, but you'd have to recompile the entire libstd in that mode if you want to get rid of all of them

Yes, you're right. They're not backtrace information, they're debug information. These could be removed in release mode (by using #[cfg(build = "debug")] in libstd).

@japaric
Copy link
Member

japaric commented Jul 24, 2016

Update: The crates in rust-lang/rust has been Cargo-ified.

I have a lightly tested fork of rust-lang/rust that makes the backtraces (RUST_BACKTRACE / libbacktrace) optional via a Cargo feature (only usable with the newer "rustbuild" build system). But even if that lands upstream, it won't be super easy to use because (a) our binary releases would still ship with backtraces enabled, (b) even if you are OK with bootstrapping rustc along with the std crate, rustbuild doesn't expose (AFAIK cc @alexcrichton) an easy way to customize the Cargo features of the std crate and (c) trying to directly build the std crate using Cargo (as in cd src/libstd && cargo build) doesn't work for some combination of Cargo features like enabling jemalloc. Also (c) is annoying because you have to package the Cargo output into a sysroot before you can use it.

TL;DR To implement this we have to decide how to expose this (optional) feature to end users.

@Ericson2314
Copy link
Contributor

@japaric #1133 while not completely solving the problems you mention is a big step in that direction.

@japaric
Copy link
Member

japaric commented Jul 26, 2016

rustbuild doesn't expose an easy way to customize the Cargo features of the std crate

Actually, there is a config.toml that rustbuild can use. I've send a PR implementing optional backtraces and exposing them via that config.toml: rust-lang/rust#35051

bors added a commit to rust-lang/rust that referenced this issue Jul 30, 2016
rustbuild: make backtraces (RUST_BACKTRACE) optional

but keep them enabled by default to maintain the status quo.

When disabled shaves ~56KB off every x86_64-unknown-linux-gnu
binary.

To disable backtraces you have to use a config.toml (see
src/bootstrap/config.toml.example for details) when building rustc/std:

$ python bootstrap.py --config=config.toml

---

r? @alexcrichton
cc rust-lang/rfcs#1417
@nrc nrc added T-dev-tools Relevant to the development tools team, which will review and decide on the RFC. T-compiler Relevant to the compiler team, which will review and decide on the RFC. labels Aug 19, 2016
@Owez
Copy link

Owez commented Oct 10, 2021

What's the current status of this?

@Avamander
Copy link

There's one more good reason for this, that hasn't been mentioned yet. I want to disable the message because re-running the panicking binary is not always a good thing to suggest to end-users.

@bjorn3
Copy link
Member

bjorn3 commented Aug 17, 2023

You can use a panic hook to disable that message, right?

@kornelski
Copy link
Contributor

Panic hook won't remove the unwanted data from the executable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-compiler Relevant to the compiler team, which will review and decide on the RFC. T-dev-tools Relevant to the development tools team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

10 participants