Repository navigation
Some debuginfo tests are not running #47163
Description
Activity
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:
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@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 }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:
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.)
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
PATHto point to a newer gdb,x.py testseems 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.rsis an existing bug that is filed in the issues.pretty-std-collections.rsis 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.rsmay be fixed by this gdb patch series (not yet landed). However, I couldn't test this, as above.compiletestseems 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.
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.
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)
- added a commit that references this issue
on Apr 9, 2021 - changed the title
[-]Debuginfo tests are not running[/-][+]Some debuginfo tests are not running[/+]on Mar 31, 2023 - added a commit that references this issue
on May 17, 2023
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