Hi Manos!
On 8/25/25 08:00, Manos Pitsidianakis wrote:
On Mon, Aug 25, 2025 at 1:31 PM Thomas Huth <th...@redhat.com> wrote:
On 19/08/2025 16.39, Gustavo Romero wrote:
The goal of this series is to remove Avocado as a dependency for running
the reverse_debugging functional test.
This test, the last one I’m aware of that relies on Avocado, requires it
because of the need for GDB to test reverse stepping and continue.
Hi!
Please note that there are currently also some efforts going on to extract
the GDB part from avocado into a more self-contained python module called
aautils, which might help here, too:
https://github.com/avocado-framework/aautils/issues/82
There's also https://github.com/cs01/pygdbmi which I have used before,
it seems like it does the same thing as avocado's gdb module but it
could be missing some functionality
Thanks for the suggestion. I recall now that I've hastily looked at pygdbmi
when writing the mte.py test.
I don't think it misses any functionality for our current purposes here, but
it has its own runner so we'll be using two different GDB runners for the
tests. I´d like to avoid it and stick with the simplest runner which doesn't
add another module dependency. The same for the test interface.
In general, pygdbmi seems more than it would be necessary for the GDB tests
we have currently. I would like to keep the tests as easy as possible to
be executed manually and I think that adding another API rather than GDB's
own Python API, currently, will not help.
Cheers,
Gustavo
In this series, we leveraged the run-test.py script used in the
check-tcg tests, making it a GDB runner capable of calling a test script
without spawning any VMs. In this configuration, the test script can
manage the VMs and also import gdb from the test script, making the
Python GDB API available inside the functional test.
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) but instead jumps to the beginning of the code (fist PC
in forward order).
At least the x86 test used to work for me most of the time, it just fails
occasionally. Same for the ppc64 test if I disable the powernv subtest there.
Thus, to run the reverse_debugging test effectively on aarch64:
$ export QEMU_TEST_FLAKY_TESTS=1
$ make check-functional
I gave it a try, but this did not work for me, the test was not run at all
anymore. Are there any patches needed on top?
Anyway, shifting to a different test harness here makes me wonder whether
the whole reverse_debug test should maybe be rather moved to tests/tcg
instead, where we already have the basic support for the stuff from
tests/guest-debug/ ?
The aarch64 would require a different guest payload, of course, in that
case, so not sure whether it's feasible?
Thomas
