Philippe Mathieu-Daudé <phi...@redhat.com> writes:
> Hi Sid,
>
> Cc'ing maintainers:
>
> $ ./scripts/get_maintainer.pl -f chardev/char.c
> "Marc-André Lureau" <marcandre.lur...@redhat.com> (maintainer:chardev)
> Paolo Bonzini <pbonz...@redhat.com> (reviewer:Character device...)
>
> $ ./scripts/get_maintainer.pl -f gdbstub.c
> "Alex Bennée" <alex.ben...@linaro.org> (maintainer:GDB stub)
> "Philippe Mathieu-Daudé" <phi...@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
