Re: [RFC PATCH 0/2] tests/functional: Adapt reverse_debugging to run w/o Avocado (yet another try)

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Sep 15, 2025 at 02:42:05PM +0200, Thomas Huth wrote:
> Here's yet another attempt to remove the avocado dependency from the
> reverse debugging tests: I basically took Gustavo's patches to rework
> tests/functional/reverse_debugging.py, but instead of calling that
> through tests/guest-debug/run-test.py and adding the cumbersome code
> to support additional test execution logic, I kept our normal way of
> running tests via pycotap. Instead, the essential logic for running
> gdb is copied from tests/guest-debug/run-test.py into the new function
> reverse_debug() that then runs gdb directly with using
> tests/functional/reverse_debugging.py as the script.

Something I've not previously realized is that when run via GDB, we are
not honouring the Python version we chose to use with QEMU. GDB is not
actually running the python interpreter binary, instead it has linked to
the libpython.so and runs python code in-process to GDB. Thus the version
of python being used is out of our control, it is whatever the distro
chose to link GDB to. When I look back at how we've handled our min
python, vs what the distros use as system python, I think the constraint
is highly undesirable.

> Marked as an RFC since this still needs some love... The aarch64 test
> seems to work already (after applying the fix for the reverse debug there
> first: https://patchew.org/QEMU/20250603125459.17688-1-1844144@gmail.com/ ),
> but the ppc64 and x86 tests are currently still completely broken.
> Also we currently log into two different folders this way, into
> tests/functional/aarch64/test_reverse_debug.ReverseDebugging_AArch64.test_aarch64_virt
> for the normal outer test, and into
> tests/functional/aarch64/reverse_debugging.ReverseDebugging.test_reverse_debugging
> for the script that is run in gdb ... it's likely ok for the aarch64
> test, but the ppc64 test contains two subtests, so we need to come up
> with a better solution here for the final implementation.

Right, this is one of the things I rather dislike with this, as it is
making debugging much more painful.

In one base.log you just get stdout from gdb with no context of what
commands are run, and in the other base.log you get the logs from the
sub-process. Well at least you would if we fixed the tests to use
self.log, instead of creating a new logger category.

Even with that fixed though, it is very difficult to correlate GDB
output in one log, with GDB commands invoke in the other log, in
order to understand why it is failing in the x86/ppc tests.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|