Some debuginfo tests are not running

[nerd2]

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

[nerd2]

Happy to have this assigned to me to work through the failing low hanging fruit tests

[nerd2]

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

[nerd2]

@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 }

[nerd2]

@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.

[tromey]

The issue is that the following is emitted as "RUST$ENCODED$ENUM$0$None".

I'm addressing this more fully in #32920.

[jonas-schievink]

Can someone give an update on this? Seems bad if we haven't run these tests for over 2 years.

[tromey]

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.)

[tromey]

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.

[tromey]

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.

[tromey]

See #71428

[spastorino]

Removing nomination, as we've discussed this in our last weekly meeting.

[tromey]

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.

[jesusprubio]

Just in case it could help. I can confirm they also fail in last Fedora (v33, GDB v10), but working for v9: #79009 (comment)