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.