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