diff mbox series

[v4,08/15] docs/devel/testing: add -gdb option to the debugging section of QEMU iotests

Message ID 20210520075236.44723-9-eesposit@redhat.com (mailing list archive)
State New, archived
Headers show
Series qemu_iotests: improve debugging options | expand

Commit Message

Emanuele Giuseppe Esposito May 20, 2021, 7:52 a.m. UTC
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
---
 docs/devel/testing.rst | 11 +++++++++++
 1 file changed, 11 insertions(+)

Comments

Vladimir Sementsov-Ogievskiy May 28, 2021, 5:16 p.m. UTC | #1
20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>

Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@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.
Emanuele Giuseppe Esposito May 28, 2021, 8:31 p.m. UTC | #2
On 28/05/2021 19:16, Vladimir Sementsov-Ogievskiy wrote:
> 20.05.2021 10:52, Emanuele Giuseppe Esposito wrote:
>> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
> 
> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@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.
> 
>
See 
https://patchew.org/QEMU/20210414170352.29927-1-eesposit@redhat.com/20210414170352.29927-5-eesposit@redhat.com/ 

(penultimate email), there was a similar question:

>> 
>> Out of interest: Why gdbserver and not “just” gdb?  On Fedora, those are 
>> separate packages, so I don’t have gdbserver installed, that’s why I’m 
>> asking.
> 
> As far as I have tried, using only gdb with ./check is very hard to use, 
> because the stdout is filtered out by the script.
> So invoking gdb attaches it to QEMU, but it is not possible to start 
> execution (run command) or interact with it, because of the python 
> script filtering. This leaves the test hanging.
> 
> gdbserver is just something that a gdb client can attach to (for 
> example, in another console or even in another host) for example with 
> the command
> # gdb -iex "target remote localhost:12345" . This provides a nice and 
> separate gdb monitor to the client.

At this point I should put this somewhere, either in commit message or 
in the actual documentation...

I don't know about the name. "gdb" should also be short for "gdbserver" 
in a way.

Thank you,
Emanuele
diff mbox series

Patch

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.