Hi Thomas,
On 8/26/25 05:06, Thomas Huth wrote:
On 25/08/2025 16.04, Gustavo Romero wrote:
...
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?
I think reverse_debugging is really a functional test. It requires GDB, yes,
but also QMP and booting a whole kernel and the feature itself makes me think
it's a functional test. I wouldn't move it to tcg-check just for the sake of
no adding a new way to run test in meson.build in functional tests.
Ok, fair point. But thinking about this twice, wouldn't it be nicer to keep the
current test harness and simply launch the script from the test_* methods
instead?
If no additional module is used, then GDB needs to execute the test_* scripts
via '-x' option
because only this way the script can do "import gdb", hence we need a runner
that will call gdb
and pass the script to it.
Naturally, we can instead use a module like pygdbmi (as Manos suggested) or
aautils (with the
caveats I mentioned about having to deal with GDB packets directly) that will
simply wrap up
calling gdb and passing it the script with subprocess etc., so no need to
augment the test harness.
The trade off I can see is: re-use the runner we use in check-tcg and augment
the test
harness to accommodate it in the functional tests _vs_ use the "runner" from
another module,
bring another python dependency and deal with another GDB API (I like using GDB
native Python
API because it's simple, sufficient and self-contained, but I'm open to
experiment with pygdbmi),
use another runner (other than the one in tests/guest-debug/test_gdbstub.py)
and don't modify the
test harness.
You could redirect stdout of the script into a log file, so that it cannot mess
with the TAP output of the test. Or is there something that I missed and this
cannot work?
Yeah, I really tried it but redirecting to a file using GDB Python
API didn't work :-(
I've tried to redirect GDB's output from the test script using
"set logging redirect on" but something is off. I even tried on GDB
master, but besides direct not taking effect (output is still printed
to the stdout) I got a GDB internal error when switching it off.
So, yes, it would work (even adding a # in the output messages so the
TAP protocol would simply ignore the lines at the same time we would
be able to see the output from GDB), but I was not able to make it work
with GDB native Python API, so turned to use the "exitcode".
Cheers,
Gustavo
