Uh oh!
There was an error while loading. Please reload this page.
Enable line number debuginfo in releases - #37280
Merged
Merged
Conversation
rust-highfive
commented
Oct 19, 2016
Contributor
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
cuviper
reviewed
Oct 19, 2016
Member
There was a problem hiding this comment.
If I use ./configure --enable-debuginfo --release-channel=stable, will I still get full debuginfo? It looks like the implicit debuginfo-lines will override that choice here.
MemberAuthor
There was a problem hiding this comment.
Good point! I'll tweak this logic.
brson
commented
Oct 19, 2016
Contributor
r=me after fixing @cuviper's concern |
This commit enables by default passing the `-C debuginfo=1` argument to the compiler for the stable, beta, and nightly release channels. A new configure option was also added, `--enable-debuginfo-lines`, to enable this behavior in developer builds as well. Closesrust-lang#36452
alexcrichton
commented
Oct 19, 2016
MemberAuthor
@bors: r=brson |
bors
commented
Oct 19, 2016
Collaborator
📌 Commit 803576c has been approved by |
bors
commented
Oct 21, 2016
Collaborator
bors added a commit
that referenced
this pull request
Oct 21, 2016
Enable line number debuginfo in releases This commit enables by default passing the `-C debuginfo=1` argument to the compiler for the stable, beta, and nightly release channels. A new configure option was also added, `--enable-debuginfo-lines`, to enable this behavior in developer builds as well. Closes#36452
bors
commented
Oct 21, 2016
Collaborator
pmarcelll
commented
Oct 23, 2016
Contributor
Two nightlies failed to build and the error messages mention debuginfo, so I guess this PR causes the failures. |
bors added a commit
that referenced
this pull request
Oct 24, 2016
Try to fix the nightlies Touching up a few pieces after the fix for #37280 landed.
alexcrichton added a commit
to alexcrichton/rust
that referenced
this pull request
Jan 11, 2017
In rust-lang#37280 we enabled line number debugging information in release artifacts, primarily to close out rust-lang#36452 where debugging information was critical for MSVC builds of Rust to be useful in production. This commit, however, apparently had some unfortunate side effects. Namely it was noticed in rust-lang#37477 that if `RUST_BACKTRACE=1` was set then any compiler error would take a very long time for the compiler to exit. The cause of the problem here was somewhat deep: * For all compiler errors, the compiler will `panic!` with a known value. This tears down the main compiler thread and allows cleaning up all the various resources. By default, however, this panic output is suppressed for "normal" compiler errors. * When `RUST_BACKTRACE=1` was set this caused every compiler error to generate a backtrace. * The libbacktrace library hits a pathological case where it spends a very long time in its custom allocation function, `backtrace_alloc`, because the compiler has so much debugging information. More information about this can be found in rust-lang#29293 with a summary at the end of rust-lang#37477. To solve this problem this commit simply removes debuginfo from the compiler but not from the standard library. This should allow us to keep rust-lang#36452 closed while also closing rust-lang#37477. I've measured the difference to be orders of magnitude faster than it was before, so we should see a much quicker time-to-exit after a compile error when `RUST_BACKTRACE=1` is set. Closesrust-lang#37477Closesrust-lang#37571
bors added a commit
that referenced
this pull request
Jan 11, 2017
rustbuild: Don't enable debuginfo in rustc In #37280 we enabled line number debugging information in release artifacts, primarily to close out #36452 where debugging information was critical for MSVC builds of Rust to be useful in production. This commit, however, apparently had some unfortunate side effects. Namely it was noticed in #37477 that if `RUST_BACKTRACE=1` was set then any compiler error would take a very long time for the compiler to exit. The cause of the problem here was somewhat deep: * For all compiler errors, the compiler will `panic!` with a known value. This tears down the main compiler thread and allows cleaning up all the various resources. By default, however, this panic output is suppressed for "normal" compiler errors. * When `RUST_BACKTRACE=1` was set this caused every compiler error to generate a backtrace. * The libbacktrace library hits a pathological case where it spends a very long time in its custom allocation function, `backtrace_alloc`, because the compiler has so much debugging information. More information about this can be found in #29293 with a summary at the end of #37477. To solve this problem this commit simply removes debuginfo from the compiler but not from the standard library. This should allow us to keep #36452 closed while also closing #37477. I've measured the difference to be orders of magnitude faster than it was before, so we should see a much quicker time-to-exit after a compile error when `RUST_BACKTRACE=1` is set. Closes#37477Closes#37571
brson pushed a commit
to brson/rust
that referenced
this pull request
Jan 17, 2017
In rust-lang#37280 we enabled line number debugging information in release artifacts, primarily to close out rust-lang#36452 where debugging information was critical for MSVC builds of Rust to be useful in production. This commit, however, apparently had some unfortunate side effects. Namely it was noticed in rust-lang#37477 that if `RUST_BACKTRACE=1` was set then any compiler error would take a very long time for the compiler to exit. The cause of the problem here was somewhat deep: * For all compiler errors, the compiler will `panic!` with a known value. This tears down the main compiler thread and allows cleaning up all the various resources. By default, however, this panic output is suppressed for "normal" compiler errors. * When `RUST_BACKTRACE=1` was set this caused every compiler error to generate a backtrace. * The libbacktrace library hits a pathological case where it spends a very long time in its custom allocation function, `backtrace_alloc`, because the compiler has so much debugging information. More information about this can be found in rust-lang#29293 with a summary at the end of rust-lang#37477. To solve this problem this commit simply removes debuginfo from the compiler but not from the standard library. This should allow us to keep rust-lang#36452 closed while also closing rust-lang#37477. I've measured the difference to be orders of magnitude faster than it was before, so we should see a much quicker time-to-exit after a compile error when `RUST_BACKTRACE=1` is set. Closesrust-lang#37477Closesrust-lang#37571
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This commit enables by default passing the
-C debuginfo=1argument to thecompiler for the stable, beta, and nightly release channels. A new configure
option was also added,
--enable-debuginfo-lines, to enable this behavior indeveloper builds as well.
Closes#36452