Message ID | 20210520075236.44723-9-eesposit@redhat.com |
---|---|
State | New |
Headers | show |
Series | qemu_iotests: improve debugging options | expand |
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.
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 --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.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> --- docs/devel/testing.rst | 11 +++++++++++ 1 file changed, 11 insertions(+)