[gdbstub] redirecting qemu console output to a debugger

[gdbstub] redirecting qemu console output to a debugger

[Sid Manning]

Currently when I attach a debugger (lldb) to my qemu session all of the output goes to the shell running qemu not to the debugger.  Fixing this meant that I needed to point the semi-hosting output to the gdb chardev.  I started qemu like this:

-s -S -semihosting-config target=auto,chardev=ch0 -chardev gdb,id=ch0

But this failed with the error:
-chardev gdb,id=ch0: 'gdb' is not a valid char driver name

In order to fix this I needed to change the stub's chardev from internal to external:

@@ -3446,7 +3446,7 @@ static void char_gdb_class_init(ObjectClass *oc, void *data)
 {
     ChardevClass *cc = CHARDEV_CLASS(oc);
 
-    cc->internal = true;
+    cc->internal = false;
     cc->open = gdb_monitor_open;
     cc->chr_write = gdb_monitor_write;
 }

Afterward console output was routed to the debugger.  This is the only chardev device I found that is marked as internal so I suspect this is the wrong thing to do.  What is the proper way to redirect output from qemu to the debugger?

Thanks,

Re: [gdbstub] redirecting qemu console output to a debugger

[Philippe Mathieu-Daudé]

Hi Sid,

Cc'ing maintainers:

$ ./scripts/get_maintainer.pl -f  chardev/char.c
"Marc-André Lureau" <marcandre.lureau@redhat.com> (maintainer:chardev)
Paolo Bonzini <pbonzini@redhat.com> (reviewer:Character device...)

$ ./scripts/get_maintainer.pl -f  gdbstub.c
"Alex Bennée" <alex.bennee@linaro.org> (maintainer:GDB stub)
"Philippe Mathieu-Daudé" <philmd@redhat.com> (reviewer:GDB stub)

On 10/21/21 14:37, Sid Manning wrote:
> Currently when I attach a debugger (lldb) to my qemu session all of the output goes to the shell running qemu not to the debugger.  Fixing this meant that I needed to point the semi-hosting output to the gdb chardev.  I started qemu like this:
> 
> -s -S -semihosting-config target=auto,chardev=ch0 -chardev gdb,id=ch0
> 
> But this failed with the error:
> -chardev gdb,id=ch0: 'gdb' is not a valid char driver name
> 
> In order to fix this I needed to change the stub's chardev from internal to external:
> 
> @@ -3446,7 +3446,7 @@ static void char_gdb_class_init(ObjectClass *oc, void *data)
>  {
>      ChardevClass *cc = CHARDEV_CLASS(oc);
>  
> -    cc->internal = true;
> +    cc->internal = false;
>      cc->open = gdb_monitor_open;
>      cc->chr_write = gdb_monitor_write;
>  }
> 
> Afterward console output was routed to the debugger.  This is the only chardev device I found that is marked as internal so I suspect this is the wrong thing to do.  What is the proper way to redirect output from qemu to the debugger?

commit 777357d758d937c9dd83082c39aff9f1e53e9ba3
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date:   Wed Dec 7 18:39:10 2016 +0300

    chardev: qom-ify

    Turn Chardev into Object.

    qemu_chr_alloc() is replaced by the qemu_chardev_new() constructor.
    It will call qemu_char_open() to open/intialize the chardev with the
    ChardevCommon *backend settings.

    The CharDriver::create() callback is turned into a
    ChardevClass::open() which is called from the newly introduced
    qemu_chardev_open().

    "chardev-gdb" and "chardev-hci" are internal chardev and aren't
    creatable directly with -chardev. Use a new internal flag to disable
    them. We may want to use TYPE_USER_CREATABLE interface instead, or
    perhaps allow -chardev usage.

    Although in general we keep typename and macros private, unless
    the type is being used by some other file, in this patch, all types
    and common helper macros for qemu-char.c are in char.h. This is to
    help transition now (some types must be declared early, while some
    aren't shared) and when splitting in several units. This is to be
    improved later.

    Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
    Reviewed-by: Eric Blake <eblake@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

I'm not sure why "chardev-gdb" is internal, maybe because it uses
static state as singleton, so can't be TYPE_USER_CREATABLE?

  static GDBState gdbserver_state;

But TYPE_DBUS_VMSTATE is TYPE_USER_CREATABLE and have:

static void
dbus_vmstate_complete(UserCreatable *uc, Error **errp)
{
    DBusVMState *self = DBUS_VMSTATE(uc);
    g_autoptr(GError) err = NULL;

    if (!object_resolve_path_type("", TYPE_DBUS_VMSTATE, NULL)) {
        error_setg(errp, "There is already an instance of %s",
                   TYPE_DBUS_VMSTATE);
        return;
    }
    ...

So it should be possible to have TYPE_CHARDEV_GDB implement
TYPE_USER_CREATABLE and check for singleton the same way,
then remove the ChardevClass::internal field IMO...

But let see what the maintainers prefer :)

Regards,

Phil.

Re: [gdbstub] redirecting qemu console output to a debugger

[Alex Bennée]

Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> Hi Sid,
>
> Cc'ing maintainers:
>
> $ ./scripts/get_maintainer.pl -f  chardev/char.c
> "Marc-André Lureau" <marcandre.lureau@redhat.com> (maintainer:chardev)
> Paolo Bonzini <pbonzini@redhat.com> (reviewer:Character device...)
>
> $ ./scripts/get_maintainer.pl -f  gdbstub.c
> "Alex Bennée" <alex.bennee@linaro.org> (maintainer:GDB stub)
> "Philippe Mathieu-Daudé" <philmd@redhat.com> (reviewer:GDB stub)
>
> On 10/21/21 14:37, Sid Manning wrote:
>> Currently when I attach a debugger (lldb) to my qemu session all of the output goes to the shell running qemu not to the debugger.  Fixing this meant that I needed to point the semi-hosting output to the gdb chardev.  I started qemu like this:
>> 
>> -s -S -semihosting-config target=auto,chardev=ch0 -chardev gdb,id=ch0

Mixing up semihosting and gdb is not going to end well. We do already
re-direct semihosting output to the debugger when it's attached. To
specify a socket for gdb to connect to you need:

  -chardev socket,path=/tmp/gdb-socket,server=on,wait=off,id=gdb0 -gdb chardev:gdb0

The -chardev specifies the details of the socket and the -gdb tells gdb
where it should make the gdbserver port visible. The only
semihosting-config variable you may want to tweak is the target.

<snip>
>
> I'm not sure why "chardev-gdb" is internal, maybe because it uses
> static state as singleton, so can't be TYPE_USER_CREATABLE?
>
>   static GDBState gdbserver_state;

One good reason - we don't support multiple connections.

>
> But TYPE_DBUS_VMSTATE is TYPE_USER_CREATABLE and have:
>
> static void
> dbus_vmstate_complete(UserCreatable *uc, Error **errp)
> {
>     DBusVMState *self = DBUS_VMSTATE(uc);
>     g_autoptr(GError) err = NULL;
>
>     if (!object_resolve_path_type("", TYPE_DBUS_VMSTATE, NULL)) {
>         error_setg(errp, "There is already an instance of %s",
>                    TYPE_DBUS_VMSTATE);
>         return;
>     }
>     ...
>
> So it should be possible to have TYPE_CHARDEV_GDB implement
> TYPE_USER_CREATABLE and check for singleton the same way,
> then remove the ChardevClass::internal field IMO...
>
> But let see what the maintainers prefer :)
>
> Regards,
>
> Phil.


-- 
Alex Bennée

RE: [gdbstub] redirecting qemu console output to a debugger

[Sid Manning]

> -----Original Message-----
> From: Alex Bennée <alex.bennee@linaro.org>
> Sent: Thursday, October 21, 2021 9:52 AM
> To: Philippe Mathieu-Daudé <philmd@redhat.com>
> Cc: Sid Manning <sidneym@quicinc.com>; Marc-André Lureau
> <marcandre.lureau@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>;
> qemu-devel@nongnu.org
> Subject: Re: [gdbstub] redirecting qemu console output to a debugger
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> 
> > Hi Sid,
> >
> > Cc'ing maintainers:
> >
> > $ ./scripts/get_maintainer.pl -f  chardev/char.c "Marc-André Lureau"
> > <marcandre.lureau@redhat.com> (maintainer:chardev) Paolo Bonzini
> > <pbonzini@redhat.com> (reviewer:Character device...)
> >
> > $ ./scripts/get_maintainer.pl -f  gdbstub.c "Alex Bennée"
> > <alex.bennee@linaro.org> (maintainer:GDB stub) "Philippe
> > Mathieu-Daudé" <philmd@redhat.com> (reviewer:GDB stub)
> >
> > On 10/21/21 14:37, Sid Manning wrote:
> >> Currently when I attach a debugger (lldb) to my qemu session all of the
> output goes to the shell running qemu not to the debugger.  Fixing this
> meant that I needed to point the semi-hosting output to the gdb chardev.  I
> started qemu like this:
> >>
> >> -s -S -semihosting-config target=auto,chardev=ch0 -chardev gdb,id=ch0
> 
> Mixing up semihosting and gdb is not going to end well. We do already re-
> direct semihosting output to the debugger when it's attached. To specify a
> socket for gdb to connect to you need:
> 
>   -chardev socket,path=/tmp/gdb-socket,server=on,wait=off,id=gdb0 -gdb
> chardev:gdb0

Thanks, this is pretty close to what I think needs to happen.  I'm using lldb and had a hard time finding the correct connection command.  For the record it is: 
(lldb) process connect unix-connect:///tmp/gdb-socket

A remaining issue is activating the gdb character device so the proper protocol packet is sent, the 'O' packet.
My command looks like this:

./qemu-system-hexagon -S -display none -monitor none -no-reboot \
-semihosting-config target=gdb,chardev=gdb0 \
-chardev socket,path=/tmp/gdb-socket,port=::1234,mux=on,server=on,wait=off,id=gdb0 \
-gdb chardev:gdb0 \
-kernel a.out

I needed to add mux=on to share gdb0.  This does indeed send the output back to the debugger, but instead of RSP 'O' packets lldb sees just plane text and drops the connection.  I need the cc->chr_write to point to gdb_monitor_write as it is it points to mux_chr_write.


> 
> The -chardev specifies the details of the socket and the -gdb tells gdb where
> it should make the gdbserver port visible. The only semihosting-config
> variable you may want to tweak is the target.
> 
> <snip>
> >
> > I'm not sure why "chardev-gdb" is internal, maybe because it uses
> > static state as singleton, so can't be TYPE_USER_CREATABLE?
> >
> >   static GDBState gdbserver_state;
> 
> One good reason - we don't support multiple connections.
> 
> >
> > But TYPE_DBUS_VMSTATE is TYPE_USER_CREATABLE and have:
> >
> > static void
> > dbus_vmstate_complete(UserCreatable *uc, Error **errp) {
> >     DBusVMState *self = DBUS_VMSTATE(uc);
> >     g_autoptr(GError) err = NULL;
> >
> >     if (!object_resolve_path_type("", TYPE_DBUS_VMSTATE, NULL)) {
> >         error_setg(errp, "There is already an instance of %s",
> >                    TYPE_DBUS_VMSTATE);
> >         return;
> >     }
> >     ...
> >
> > So it should be possible to have TYPE_CHARDEV_GDB implement
> > TYPE_USER_CREATABLE and check for singleton the same way, then
> remove
> > the ChardevClass::internal field IMO...
> >
> > But let see what the maintainers prefer :)
> >
> > Regards,
> >
> > Phil.
> 
> 
> --
> Alex Bennée