This is an archive of the discontinued LLVM Phabricator instance.

[cross-project-tests] XFAIL llgdb-tests when gdb can't read clang's DWARF
ClosedPublic

Authored by Orlando on Jan 28 2022, 6:50 AM.

Details

Summary

Tests in the cross-project-tests/debuginfo-tests/llgdb-tests directory run gdb on non-darwin platforms. gdb versions less than 10.1 cannot parse the DWARF v5 emitted by clang, and DWARF v5 is now the default, so these tests fail on Linux with gdb versions less than 10.1. This patch lets us XFAIL the tests under these conditions.

Add 'gdb-clang-incompatibility' to the available_features in cross-project-tests/lit.cfg.py when clang's default DWARF version is 5 or greater and the gdb (if found) version is less than 10.1.

The patch isn't particularly pretty, but I think it might be the least-bad thing to do. We can't add XFAIL: system-linux to these tests because they will "unexpectedly pass" if a compatible gdb is installed. We could force the tests to emit v4 instead, but that undermines the point of the tests, which is to check that the platform debugger works with the just-build clang [0]. The only alternative I can think of is to add UNSUPPORTED: system-linux to these tests, but losing the coverage is undesirable.

Discourse discussion: https://llvm.discourse.group/t/gdb-10-1-cant-read-clangs-dwarf-v5/6035
[0]: https://llvm.discourse.group/t/gdb-10-1-cant-read-clangs-dwarf-v5/6035/4?u=ochyams

Diff Detail

Event Timeline

Orlando requested review of this revision.Jan 28 2022, 6:50 AM
Orlando created this revision.
ormris added a subscriber: ormris.Jan 28 2022, 10:03 AM

LGTM but I'd rather have @aprantl or @JDevlieghere review because I believe the llgdb tests are something Apple did? I'm happy to approve if I'm wrong.

dyung added a subscriber: dyung.Jan 31 2022, 9:19 PM

Thanks for taking a look @probinson. Adding Jeremy as reviewer.

Ping

We've now got a native Linux builder in staging where you can see these tests failing: https://lab.llvm.org/staging/#/builders/205/builds/91

jmorse added a comment.Feb 7 2022, 3:21 AM

SGTM with a couple of nits. From the discussion on discourse, I think it's a deliberate choice that there's going to be incompatible configurations out there, in which case as you say the least-worst-option is xfailing these tests.

In addition, I think it'll be worth printing a warning to the developer when the tests start running that because their gdb version is out of date, they won't get full test coverage. That gives developers a sporting chance to spot the problem, otherwise we're silently suppressing information.

cross-project-tests/lit.cfg.py
212–215

Would this benefit from a pokemon exception handler? Given that we're calling another process, there's a nonzero possibility we'll get a CalledProcessError or some other unexpected behaviour. I'd suggest that if gdb itself is broken, we should catch the resulting exceptions here, return None, and let the gdb tests run and possibly fail. IMO, that's better than presenting an exception in llvm-lit to the developer.

220

Having the same length-check for [2] as on the earlier few lines would future proof this code.

Orlando updated this revision to Diff 406396.Feb 7 2022, 4:27 AM
Orlando marked 2 inline comments as done.

Thanks @jmorse

+ Catch-em-all when trying to run gdb
+ Print a message when the XFAIL condition is detected.
+ Fix stderr -> sys.stderr in a print call.

cross-project-tests/lit.cfg.py
212–215

SGTM, done.

220

partition returns a 3-tuple of strings (docs).

Orlando updated this revision to Diff 406399.Feb 7 2022, 4:36 AM

+ Make gdb-version-check more robust by checking version string length

Orlando added inline comments.Feb 7 2022, 4:38 AM
cross-project-tests/lit.cfg.py
220

I have now updated this to check that the partition isn't zero-length though.

jmorse accepted this revision.Feb 9 2022, 2:39 AM

LGTM

This revision is now accepted and ready to land.Feb 9 2022, 2:39 AM