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