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

Work around invalid DWARF bugs for fat LTO #89041

Merged
merged 1 commit into from
Sep 22, 2021

Conversation

sticnarf
Copy link
Contributor

This PR applies the same workaround in #46772 to fat LTO.

It seems to fix the bug reported in #66118 (comment).

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @oli-obk (or someone else) soon.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 17, 2021
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@sticnarf sticnarf force-pushed the sticnarf/fat-lto-dwarf branch 2 times, most recently from 1ee8d6f to 379a661 Compare September 17, 2021 13:14
@oli-obk
Copy link
Contributor

oli-obk commented Sep 17, 2021

r? rust-lang/wg-llvm

@oli-obk
Copy link
Contributor

oli-obk commented Sep 17, 2021

r? @rust-lang/wg-llvm can one of you take this?

Signed-off-by: Yilin Chen <sticnarf@gmail.com>
@nagisa
Copy link
Member

nagisa commented Sep 17, 2021

r? @nagisa

@rust-highfive rust-highfive assigned nagisa and unassigned oli-obk Sep 17, 2021
@nagisa
Copy link
Member

nagisa commented Sep 17, 2021

Can you please add a regression test? If its too hard then its okay to r=me this.

@sticnarf
Copy link
Contributor Author

Can you please add a regression test? If its too hard then its okay to r=me this.

Sorry but now I don't know how to construct a minimized case for reproducing the issue from Rust code (as you see the code I posted in the issue page has multiple dependencies, and the issue disappears after removing any of them). So I'm afraid it's really too hard for me to add a regression test for it.

@nagisa
Copy link
Member

nagisa commented Sep 18, 2021

@bors r+

@bors
Copy link
Contributor

bors commented Sep 18, 2021

📌 Commit d5de680 has been approved by nagisa

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 18, 2021
the8472 added a commit to the8472/rust that referenced this pull request Sep 22, 2021
…nagisa

Work around invalid DWARF bugs for fat LTO

This PR applies the same workaround in rust-lang#46772 to fat LTO.

It seems to fix the bug reported in rust-lang#66118 (comment).
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 22, 2021
Rollup of 8 pull requests

Successful merges:

 - rust-lang#89036 (Fix missing `no_global_oom_handling` cfg-gating)
 - rust-lang#89041 (Work around invalid DWARF bugs for fat LTO)
 - rust-lang#89046 ("Fix" an overflow in byte position math)
 - rust-lang#89127 (Re-enable the `src/test/debuginfo/mutex.rs` test on Windows)
 - rust-lang#89133 (Fix ICE with `--cap-lints=allow` and `-Zfuel=...=0`)
 - rust-lang#89162 (rustc_index: Add some map-like APIs to `IndexVec`)
 - rust-lang#89164 (Document `--show-type-layout` in the rustdoc book)
 - rust-lang#89170 (Disable the leak sanitizer on Macos aarch64 for now)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 1deef1f into rust-lang:master Sep 22, 2021
@rustbot rustbot added this to the 1.57.0 milestone Sep 22, 2021
let mut cu1 = ptr::null_mut();
let mut cu2 = ptr::null_mut();
unsafe { llvm::LLVMRustLTOGetDICompileUnit(llmod, &mut cu1, &mut cu2) };
if !cu2.is_null() {
Copy link
Contributor

Choose a reason for hiding this comment

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

The Thin LTO use of this seems to have the opposite check? It only proceeds if cu2 is nul.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oops... I didn't mean to do the opposite, actually.

However, after the patch, rustc seems to generate valid dwarf for binaries (such as ripgrep) while using full LTO. So I truly misunderstood something.

I am not sure how much missing debug info it will increase. But at least Linux perf does not show unknown userspace addresses in my practice...

Copy link
Contributor

Choose a reason for hiding this comment

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

I tried it out. It seems to be doing what I expect (puts everything in one huge CU), and this check makes sense to me (it's only worth trying to combine CUs if there is more than one CU), so it's probably just the comment that is wrong.

@sticnarf
Copy link
Contributor Author

sticnarf commented Nov 5, 2021

It seems quite some regressions are reported due to this PR. Better to revert this immature workaround.

@cbiffle
Copy link
Contributor

cbiffle commented Apr 4, 2022

It seems quite some regressions are reported due to this PR. Better to revert this immature workaround.

Can't really tell from the github output here, did this happen? This change without regression tests has been suggested as the culprit for broken DWARF output for static vars in LTO'd binaries over in #90357.

If this is still in-tree we can try reverting it on our side, I suppose.

cbiffle added a commit to oxidecomputer/rust that referenced this pull request Apr 5, 2022
Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See rust-lang#90357 for more info
and a repro case.

This commit is a mechanical revert of
d5de680 from PR rust-lang#89041, which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)

I have locally verified that this fixes rust-lang#90357 by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
fee1-dead added a commit to fee1-dead-contrib/rust that referenced this pull request Apr 15, 2022
… r=pnkfelix

Revert "Work around invalid DWARF bugs for fat LTO"

Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See rust-lang#90357 for more info
and a repro case.

This commit is a mechanical revert of
d5de680 from PR rust-lang#89041, which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)

I have locally verified that this fixes rust-lang#90357 by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
RalfJung added a commit to RalfJung/rust that referenced this pull request Apr 15, 2022
… r=pnkfelix

Revert "Work around invalid DWARF bugs for fat LTO"

Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See rust-lang#90357 for more info
and a repro case.

This commit is a mechanical revert of
d5de680 from PR rust-lang#89041, which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)

I have locally verified that this fixes rust-lang#90357 by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
RalfJung added a commit to RalfJung/rust that referenced this pull request Apr 15, 2022
… r=pnkfelix

Revert "Work around invalid DWARF bugs for fat LTO"

Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See rust-lang#90357 for more info
and a repro case.

This commit is a mechanical revert of
d5de680 from PR rust-lang#89041, which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)

I have locally verified that this fixes rust-lang#90357 by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
RalfJung added a commit to RalfJung/rust that referenced this pull request Apr 15, 2022
… r=pnkfelix

Revert "Work around invalid DWARF bugs for fat LTO"

Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See rust-lang#90357 for more info
and a repro case.

This commit is a mechanical revert of
d5de680 from PR rust-lang#89041, which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)

I have locally verified that this fixes rust-lang#90357 by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Apr 15, 2022
… r=pnkfelix

Revert "Work around invalid DWARF bugs for fat LTO"

Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See rust-lang#90357 for more info
and a repro case.

This commit is a mechanical revert of
d5de680 from PR rust-lang#89041, which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)

I have locally verified that this fixes rust-lang#90357 by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 16, 2022
…=pnkfelix

Revert "Work around invalid DWARF bugs for fat LTO"

Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See rust-lang#90357 for more info
and a repro case.

This commit is a mechanical revert of
d5de680 from PR rust-lang#89041, which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)

I have locally verified that this fixes rust-lang#90357 by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
@jieyouxu jieyouxu added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-LTO Area: Link-time optimization (LTO) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 14, 2024
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.) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-LTO Area: Link-time optimization (LTO) S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants