-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Some debuginfo tests are not running #47163
Comments
Happy to have this assigned to me to work through the failing low hanging fruit tests |
PR #47155 has now landed, the following tests were disabled: |
@eddyb I had a brief look at option-like-enum.rs and it seems that the DWARF emitted is hardcoding the descriminant to the 0th field? Looked like you had done most recent work in this area. The issue is that the following is emitted as "RUST$ENCODED$ENUM$0$None". Same if the first field of "Full" is u64. cc @tromey i notice you are working in this area too
|
Debuginfo Shadowed Variable test: fix check numbering Appears to be a simple fix to restore this test. Ref issue rust-lang#47163, CC @arielb1
I'm addressing this more fully in #32920. |
Can someone give an update on this? Seems bad if we haven't run these tests for over 2 years. |
Many tests are still commented out. On my Fedora 30 system, I get one failure with the system gdb; and when I remove the comments I see:
(I'm omitting some lldb failures here as not relevant.) |
I read through the failures. However, I tried to re-run the tests against various versions of gdb, and I found I couldn't reliably do this... if I change my Most of these failures occur when gdb prints something reasonable, but just not exactly what the test case happens to expect. I think
Python Exception <class 'gdb.error'> No type named alloc::collections::btree::node::Root<i32, i32.:
Python Exception <class 'gdb.error'> No type named alloc::collections::btree::node::Root<bool, bool>.:
Python Exception <class 'gdb.error'> No type named alloc::collections::btree::node::Root<i32, pretty_std_collections::MyLeafNode.: I suspect
Which versions of gdb ought to be tested? It's been a while since I looked at this stuff, so I no longer remember the state. |
I have a patch for this that I will send soon. |
See #71428 |
Removing nomination, as we've discussed this in our last weekly meeting. |
I read the meeting notes. Note that #71428 just fixes a bug that prevents running the tests against git master gdb. It does not touch the tests. I still don't know which versions of gdb are / can be tested or where to look for that. But it sounds like perhaps these tests are deprecated anyway. |
Just in case it could help. I can confirm they also fail in last Fedora (v33, GDB v10), but working for v9: #79009 (comment) |
Stepping through a debugger is more difficult now Boehm has its own SIGSEGV handler. These tests are deprecated anyway, and the rust team are working on removing them. More info: rust-lang#47163
Bug rust-lang#47163 points out that some debug tests were disabled. This patch re-enables many of them for gdb (I don't know enough about recent versions of lldb to make this change there). One test that only works for a relatively new gdb, due to the use of DW_ATE_UTF, is moved to a version-specific test. In a couple of spot, I simplified the check expression where I thought that it made sense to do so -- sometimes it isn't very worthwhile to match exactly what is emitted, particularly where this has changed over time. I tested this with both a DW_ATE_UTF-capable gdb, and an older version.
Stepping through a debugger is more difficult now Boehm has its own SIGSEGV handler. These tests are deprecated anyway, and the rust team are working on removing them. More info: rust-lang#47163
I noticed when adding a debuginfo test that nothing I did caused the test to fail. Tracing back this seems to have been caused by 3e6c83d which broke parsing of the command/check lines, leaving all tests passing without any checking.
PR #47155 runs them again and ignores the failing ones
The text was updated successfully, but these errors were encountered: