Thomas Huth <[email protected]> writes: > On 03/10/2025 16.18, Gustavo Romero wrote: >> The goal of this series is to remove Avocado as a dependency for running >> the reverse_debugging functional test. >> After several rounds of discussions about v1 and v2, and experiments >> done by Daniel and Thomas (thanks for all the experiments and comments >> so far), I've taken a new approach and moved away from using a runner >> for GDB. The changes, I believe, are much simpler now. >> This new series uses GDB's machine interface (MI) via the pygdbmi >> module >> (thanks Manos and Peter for the inputs). pygdbmi provides a controller >> to start GDB and communicate with it through MI, so there is no longer a >> risk of version clashes between libpython in GDB and Python modules in >> the pyvenv, as it could, in theory, happen when GDB executes the test >> script via -x option. >> Also, as Daniel pointed out, the overall test output is pretty bad >> and >> currently does not allow one to easily follow the sequence of GDB >> commands used in the test. I took this opportunity to improve the output >> and it now prints the sequence in a format that can be copied and pasted >> directly into GDB. >> The TAP protocol is respected, and Meson correctly displays GDB's >> test >> output in testlog-thorough.txt. >> Because the pygdbmi "shim" is so thin, I had to write a trivial GDB >> class around it to easily capture and print the payloads returned by its >> write() method. The GDB class allows clean, single-line commands to be >> used in the tests through method chaining, making them easier to follow, >> for example: >> pc = gdb.cli("print $pc").get_add() >> The test is kept “skipped” for aarch64, ppc64, and x86_64, so it is >> necessary to set QEMU_TEST_FLAKY_TESTS=1 in the test environment to >> effectively run the test on these archs. >> On aarch64, the test is flaky, but there is a fix that I’ve tested >> while >> writing this series [0] that resolves it. On ppc64 and x86_64, the test >> always fails: on ppc64, GDB gets a bogus PC, and on x86_64, the last >> part of the test (reverse-continue) does not hit the last executed PC >> (as it should happen) but instead jumps to the beginning of the code >> (first PC in forward order). >> Thus, to effectively run the reverse_debugging test on aarch64: >> $ export QEMU_TEST_FLAKY_TESTS=1 >> $ make check-functional >> or: >> $ make check-functional-aarch64 >> or even, to run only the reverse_debug test after 'make >> check-functional': >> $ ./pyvenv/bin/meson test --verbose --no-rebuild -t 1 --setup thorough >> --suite func-thorough func-aarch64-reverse_debug >> Cheers, >> Gustavo >> v1: >> https://patchew.org/QEMU/[email protected]/ >> v2: >> https://patchew.org/QEMU/[email protected]/ >> v3: >> https://patchew.org/QEMU/[email protected]/ >> v4: >> https://patchew.org/QEMU/[email protected]/ >> v5: >> https://patchew.org/QEMU/[email protected]/ >> v6: >> - Fixed skipping test when no GDB is installed in the test environment > > With this v6, the test now gets skipped in my incremental build > directory, and it works when I compile QEMU in a new folder. I guess > that's good enough, so from my side, it's fine to include this now: > > Tested-by: Thomas Huth <[email protected]> > > Alex, will you queue the patches?
Yep - I'm just doing the final checks with my personal gitlab runners before posting. > > Thomas -- Alex Bennée Virtualisation Tech Lead @ Linaro
