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

[Emanuele Giuseppe Esposito]

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