-
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
Reenable debuginfo tests #95696
Reenable debuginfo tests #95696
Conversation
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.
- 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.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @lcnr (or someone else) soon. Please see the contribution instructions for more information. |
(More context available in #95685, fwiw.) |
Welp. One of these tests appears to segfault rustc under certain circumstances. Guess I'll turn it back off.
|
These tests were disabled four years ago; it appears that it was intended to be temporary. In that time their assertions have rotted. I've gone through and fixed the assertions where necessary and rehabilitated them. In several cases I've had to leave lldb disabled, because the lldb output has changed in ways that I don't understand. I figured gdb coverage was better than no coverage. It's worth noting that these tests being enabled would probably have caught the regression observed in rust-lang#90357.
664036d
to
d59a793
Compare
hey 👋 is there anything to review right now? If so please comment |
Sorry, this is based on another PR (#95685) that I thought was headed for review. Without it, the tests don't pass. I'll update when that's in. |
Oh, excellent! I started working on re-enabling many of these as well in #94489 but I haven't had much time lately to work on that. I'm happy to review & approve your changes instead! r? @wesleywiser |
Thanks! The PR to fix the debuginfo generation has been approved, once that's rolled up I'll rebase this and set it to ready (and CC you). |
triage: Hi @cbiffle, it looks like the fix PR you mentioned has been merged. Is this just in need of a rebase and review? |
Oh hi! Yes, I believe that is correct. Lemme set the ready bit. |
Hi, I think this might need a rebase first! (Unless you feel that a review first would be helpful.) Either way, please then post a comment with |
Triage - doesn't seem to be in ready state? Not sure what's causing this
@rustbot ready - setting it to ready anyway |
??? ok, setting it manually and I'll follow up with #t-infra |
These tests were disabled four years ago; it appears that it was
intended to be temporary.
In that time their assertions have rotted. I've gone through and fixed
the assertions where necessary and rehabilitated them. In several cases
I've had to leave lldb disabled, because the lldb output has changed in
ways that I don't understand. I figured gdb coverage was better than no
coverage.
It's worth noting that these tests being enabled would probably have
caught the regression observed in #90357.