-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Revert "Work around invalid DWARF bugs for fat LTO" #95685
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @compiler-errors (or someone else) soon. Please see the contribution instructions for more information. |
r? @pnkfelix since you self-assigned the attached issue (and I know very little about codegen) |
@cbiffle do you think you could add tests for this in src/test/debuginfo so it doesn't regress again? |
Happy to give it a shot! A modification to Is it worth attempting to matrix the debug tests across different build settings so that there aren't omissions like this? |
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.
68800da
to
3f48e92
Compare
So, there were some tests that would have caught this, except that (1) they were "temporarily" disabled in 2018 and (2) they were using the wrong build configuration. Altering
I've added a commit to this PR that re-enables the test and adds a duplicate of it using LTO. Both tests pass with this PR; the LTO test fails without it, reproducing the bug. I admit I don't understand the circumstances that led to these tests being disabled in #47155, so I don't know for sure that simply turning them back on and fixing the decay is the right answer. Also, if there is a way to matrix a single test case in multiple build configurations rather than copy-pasta, please let me know. |
Also, for what it's worth, I've managed to update and re-enable 16 debuginfo tests, some simply by turning them back on, some by updating rotten assertions about GDB's output. It looks like there's been some regression in lldb's output in some cases, unrelated to rustc's DWARF generation, so in some cases I've left them disabled for lldb. If there's interest in this change I can create a followup PR. |
That sounds amazing! |
Slick. That's almost exactly what I wanted. Unfortunately, any attempt to use |
- Re-enabled basic-types-globals which has been disabled since 2018 - Updated its now-rotted assertions about GDB's output to pass - Rewrote header comment describing some previous state of GDB behavior that didn't match either the checked-in assertions _or_ the current behavior, and so I assume has just been wrong for some time. - Copy-pasta'd the test into a version that uses LTO to check for regression on rust-lang#90357, because I don't see a way to matrix the same test into several build configurations.
3f48e92
to
42af197
Compare
Posted as a draft in #95696 . It's based on top of this PR for my convenience. If it seems like this PR is going to be controversial I can rebase and separate them. |
Hi! Is anybody looking at this? Can I do anything to facilitate? Thanks! |
Hi @cbiffle , I'm looking at it now. Hopefully will merge soon. |
This is pretty easy justification for a revert here. :) Thanks @cbiffle ! @bors r+ rollup |
📌 Commit 42af197 has been approved by |
… 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.
… 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.
What is the status of this PR? Does bors need to try again? |
@GrantM11235 it failed the multiplatform tests - someone (presumably @cbiffle, although other people can take it over if they don't have time) needs to figure out why and fix the tests. |
@jyn514 I'd like to help however I can, but I don't understand the failure these hit. |
@pnkfelix or anyone else, do you understand the build failure here? We're getting increasingly far behind the rust-embedded ecosystem because they're using features that became available after DWARF generation broke, whereas we require DWARF generation. I'd like to do what I can to move this along but my fix works on the platforms I have access to. |
The build failure is because the newly reenabled tests fail. It looks like #95138 also tried to reenable gdb tests, but also ran into failures. Most likely, these don't work under gdb 7, but work under some newer version. You could try adding a min-gdb-version annotation. |
Ping from triage: |
@rustbot ready Spoke w/ @cbiffle to help get this landed. I updated the test to include a minimum GDB version. The CI job linked above that failed was using While this does mean it won't be run on some of the CI machines, we already have a number of tests that specify a minimum GDB version of anywhere from 7.7 to 10.1. This should still give us some coverage (e.g. |
@bors r=pnkfelix rollup=never Thanks! |
⌛ Testing commit 2085d6a with merge 1d91b6bba8269b811ffc115121616b3d0d2ef43f... |
☀️ Test successful - checks-actions |
Finished benchmarking commit (e6c43cf): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
compiletest: Allow using revisions with debuginfo tests. A small wart that came up in rust-lang#95685 (comment).
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 #90357 for more info
and a repro case.
This commit is a mechanical revert of
d5de680 from PR #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 #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.