Some debuginfo tests are not running

Opened by Sam Lancia at 2023-03-31 07:54:07

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

Happy to have this assigned to me to work through the failing low hanging fruit tests
Sam Lancia at 2018-01-03 18:28:33
PR #47155 has now landed, the following tests were disabled: basic-types-globals-metadata.rs // ignore-gdb basic-types-globals.rs // ignore-gdb basic-types-metadata.rs // ignore-gdb basic-types-mut-globals.rs // ignore-gdb by-value-non-immediate-argument.rs // ignore-test c-style-enum.rs // ignore-gdb drop-locations.rs // ignore-test function-arg-initialization.rs // ignore-test function-prologue-stepping-regular.rs // ignore-test lexical-scopes-in-block-expression.rs // ignore-gdb limited-debuginfo.rs // ignore-gdb macro-stepping.rs // ignore-gdb method-on-enum.rs // ignore-test option-like-enum.rs // ignore-test pretty-std.rs // ignore-test shadowed-variable.rs // ignore-test simple-struct.rs // ignore-gdb simple-tuple.rs // ignore-gdb struct-in-enum.rs // ignore-test type-names.rs // ignore-gdb union-smoke.rs // ignore-gdb vec-slices.rs // ignore-gdb vec.rs // ignore-gdb
Sam Lancia at 2018-01-06 09:25:07
@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

enum MoreFields<'a> { Full(u32, &'a isize, i16), Empty }
Sam Lancia at 2018-01-06 09:51:55
@arielb1 @vadimcn Looking at drop-locations.rs, various of the #locs are skipped. I notice that going from "-O" to "-C opt-level=0" fixes the test, on osx at least, but I wasn't sure if that was a valid fix or if this test should still work at O2.
Sam Lancia at 2018-01-06 09:54:49
The issue is that the following is emitted as "RUST$ENCODED$ENUM$0$None".

I'm addressing this more fully in #32920.
Tom Tromey at 2018-01-07 06:10:55
Can someone give an update on this? Seems bad if we haven't run these tests for over 2 years.
Jonas Schievink at 2020-04-20 23:08:23
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:
```
failures:
    [debuginfo-gdb] debuginfo/basic-types-metadata.rs
    [debuginfo-gdb] debuginfo/macro-stepping.rs
    [debuginfo-gdb] debuginfo/pretty-std-collections.rs
    [debuginfo-gdb] debuginfo/type-names.rs
```
(I'm omitting some lldb failures here as not relevant.)
Tom Tromey at 2020-04-21 18:48:52
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 PATH to point to a newer gdb, x.py test seems to run a different number of tests. I don't know why this happens or what to do about it, but anyway it prevents a full investigation.

Most of these failures occur when gdb prints something reasonable, but just not exactly what the test case happens to expect.

I think macro-stepping.rs is an existing bug that is filed in the issues.

pretty-std-collections.rs is probably a bug in the pretty-printers:
```
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 type-names.rs may be fixed by this gdb patch series (not yet landed). However, I couldn't test this, as above.

compiletest seems confused by what the git gdb prints as its version number. (I tried to hack around this...)

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.
Tom Tromey at 2020-04-21 19:30:13
compiletest seems confused by what the git gdb prints as its version number. (I tried to hack around this...)

I have a patch for this that I will send soon.
Tom Tromey at 2020-04-22 13:36:43
See #71428
Tom Tromey at 2020-04-22 13:56:30
Removing nomination, as we've discussed this in our last weekly meeting.
Santiago Pastorino at 2020-04-23 15:56:11
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.
Tom Tromey at 2020-04-23 21:19:33
Just in case it could help. I can confirm they also fail in last Fedora (v33, GDB v10), but working for v9: https://github.com/rust-lang/rust/issues/79009#issuecomment-771185624
Jesús Rubio at 2021-02-01 21:58:55