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

Enable line number debuginfo in releases #37280

Merged
merged 1 commit into from
Oct 21, 2016
Merged

Conversation

alexcrichton
Copy link
Member

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

@rust-highfive
Copy link
Collaborator

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

@@ -143,6 +143,11 @@ ifdef CFG_ENABLE_DEBUGINFO
CFG_RUSTC_FLAGS += -g
endif

ifdef CFG_ENABLE_DEBUGINFO_LINES
$(info cfg: enabling line number debuginfo (CFG_ENABLE_DEBUGINFO_LINES))
CFG_RUSTC_FLAGS += -C debuginfo=1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! I'll tweak this logic.

@brson
Copy link
Contributor

brson commented Oct 19, 2016

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.

Closes rust-lang#36452
@alexcrichton
Copy link
Member Author

@bors: r=brson

@bors
Copy link
Contributor

bors commented Oct 19, 2016

📌 Commit 803576c has been approved by brson

@brson brson added the relnotes Marks issues that should be documented in the release notes of the next release. label Oct 19, 2016
@bors
Copy link
Contributor

bors commented Oct 21, 2016

⌛ Testing commit 803576c with merge e470827...

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 bors merged commit 803576c into rust-lang:master Oct 21, 2016
@pmarcelll
Copy link
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 alexcrichton deleted the debuginfo branch November 6, 2016 16:34
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.

Closes rust-lang#37477
Closes rust-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 #37477
Closes #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.

Closes rust-lang#37477
Closes rust-lang#37571
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Marks issues that should be documented in the release notes of the next release.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants