From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Gustavo Romero <gustavo.romero@linaro.org>
Cc: qemu-devel@nongnu.org, alex.bennee@linaro.org, thuth@redhat.com,
qemu-arm@nongnu.org, 1844144@gmail.com
Subject: Re: [PATCH v2 0/5] tests/functional: Adapt reverse_debugging to run w/o Avocado
Date: Mon, 8 Sep 2025 12:49:05 +0100 [thread overview]
Message-ID: <aL7CsSppNc-WZFY-@redhat.com> (raw)
In-Reply-To: <20250904154640.52687-1-gustavo.romero@linaro.org>
On Thu, Sep 04, 2025 at 03:46:35PM +0000, Gustavo Romero wrote:
> 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 scripts can
> manage the VM and also import gdb, making the GDB Python API inside the
> functional test scripts.
>
> A --quiet option has been added to run-test.py so it doesn't print the
> command line used to execute GDB to the stdout. This ensures that users
> don't get confused about how to re-run the tests. One can re-run the
> test simply by copying and pasting the command line shown by Meson when
> V=1 is passed:
>
> $ make -j check-functional V=1
>
> or, alternatively, once the test run completes, the exact command found
> in the 'command:' field of the build/meson-logs/testlog-thorough.txt
> file generated by Meson. Both methods provide the correct environment
> variables required to run the test, such as the proper $PYTHONPATH.
While I like the conceptual idea of just sending human GDB commands,
instead of working with GDB protocol packets, I really dislike the
effect this has on the execution / startup of the functional tests
via use of the custom runner for a number of reasons
* The command line for launching the test outside of meson is very
complicated, so not memorable
* It makes the meson.build rules much more complicated
* Running standalone there is no TAP output available making the
test hard to debug on failure or timeout
I understand the need to spawn the test via gdb, in order to be able
to import the 'gdb' python module. Looking at what reverse_debugging.py
does, however, makes me question whether we actually need to directly
use the 'gdb' python module.
The only APIs we use are 'gdb.execute' and 'gdb.parse_and_eval'.
The latter is only used once as
gdb.parse_and_eval("$pc")
and I believe that can be changed to
gdb.execute("printf \"0x%x\", $pc", to_string=True)
IOW, all we need is 'gdb.execute("....", to_string=True)'
With a little extra helper proxy script, we can achieve this without
changing the way scripts are launched.
The script needs to listen on a UNIX socket path. When a client
connects, it should read lines of data from the client and pass
them to 'gdb.execute(..., to_string=True)' and whatever data
gdb returns should be written back to the client.
A very very crude example with no error handling would be:
#!/usr/bin/python3
import gdb
import os
import socket
sock = os.environ.get("QEMU_PROXY", "/tmp/qemu.gdb.proxy")
try:
os.unlink(sock)
except:
pass
with socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) as s:
s.bind(sock)
s.listen()
conn, addr = s.accept()
fh = conn.makefile('rw')
with conn:
while True:
line = fh.readline()
if not line:
break
data = gdb.execute(line, to_string=True)
fh.write(data)
fh.flush()
In the functional test suite, we should have a helper file
tests/functional/qemu_test/gdb.py that provides an API for
launching GDB to execute this proxy script, and an API to
execute commands by talking over this UNIX socket path.
With this, we will need no changes in the way we execute the
reverse debugging script from a test runner POV, thus avoiding
all the downsides of use of the run-test.py script. IOW, the
first 4 patches in this series go away completely. Instead we
need a patch to create the proxy script and a patch to create
the helper APIs in tests/functional/qemu_test/gdb.py, whereupon
the last patch can replace
try:
import gdb
except ModuleNotFoundError:
from sys import exit
exit("This script must be launched via tests/guest-debug/run-test.py!")
with
from qemu_test import gdb
and the earlier mentioned replacement of parse_and_eval()
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 :|
next prev parent reply other threads:[~2025-09-08 11:49 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-04 15:46 [PATCH v2 0/5] tests/functional: Adapt reverse_debugging to run w/o Avocado Gustavo Romero
2025-09-04 15:46 ` [PATCH v2 1/5] tests/guest-debug: Make QEMU optional in run-test.py Gustavo Romero
2025-09-05 7:22 ` Alex Bennée
2025-09-08 9:02 ` Thomas Huth
2025-09-04 15:46 ` [PATCH v2 2/5] tests/guest-debug: Format comments Gustavo Romero
2025-09-05 7:22 ` Alex Bennée
2025-09-08 9:03 ` Thomas Huth
2025-09-04 15:46 ` [PATCH v2 3/5] tests/guest-debug: Add quiet option to run-tests.py Gustavo Romero
2025-09-05 7:21 ` Alex Bennée
2025-09-08 9:12 ` Thomas Huth
2025-09-04 15:46 ` [PATCH v2 4/5] tests/functional: Support tests that require a runner Gustavo Romero
2025-09-08 9:21 ` Thomas Huth
2025-09-04 15:46 ` [PATCH v2 5/5] tests/functional: Adapt reverse_debugging to run w/o Avocado Gustavo Romero
2025-09-05 7:21 ` Alex Bennée
2025-09-08 9:16 ` Daniel P. Berrangé
2025-09-11 23:50 ` Gustavo Romero
2025-09-08 11:49 ` Daniel P. Berrangé [this message]
2025-09-11 23:51 ` [PATCH v2 0/5] " Gustavo Romero
2025-09-12 14:49 ` Daniel P. Berrangé
2025-09-12 16:04 ` Alex Bennée
2025-09-12 16:27 ` Daniel P. Berrangé
2025-09-12 16:50 ` Peter Maydell
2025-09-15 12:49 ` Thomas Huth
2025-09-15 22:11 ` Gustavo Romero
2025-09-15 8:29 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aL7CsSppNc-WZFY-@redhat.com \
--to=berrange@redhat.com \
--cc=1844144@gmail.com \
--cc=alex.bennee@linaro.org \
--cc=gustavo.romero@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.