20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
Signed-off-by: Emanuele Giuseppe Esposito <eespo...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
---
docs/devel/testing.rst | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index 8144e316a4..a746cab745 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -229,6 +229,17 @@ Debugging a test case
The following options to the ``check`` script can be useful when debugging
a failing test:
+* ``-gdb`` wraps every QEMU invocation in a ``gdbserver``, which waits for a
+ connection from a gdb client. The options given to ``gdbserver`` (e.g. the
+ address on which to listen for connections) are taken from the
``$GDB_OPTIONS``
+ environment variable. By default (if ``$GDB_OPTIONS`` is empty), it listens
on
+ ``localhost:12345``.
+ It is possible to connect to it for example with
+ ``gdb -iex "target remote $addr"``, where ``$addr`` is the address
+ ``gdbserver`` listens on.
+ If the ``-gdb`` option is not used, ``$GDB_OPTIONS`` is ignored,
+ regardless on whether it is set or not.
+
* ``-d`` (debug) just increases the logging verbosity, showing
for example the QMP commands and answers.
Didn't you think of an interface as simple as just wrap qemu binary by "gdb --args"
and redirect stdin and stdout directly to the terminal where test is running? Wouldn't it more
convenient? So, you just start ./check -gdb <test>, and you are in gdb. Or you need
exactly gdb server, to attach from another machine?
Keeping this possibility in mind, it's probably better to call you option
"-gdbserver"... But we can rename later if needed, finally, it's only a test
framework.
--
Best regards,
Vladimir
