> -----Original Message-----
> From: Alex Bennée <alex.ben...@linaro.org>
> Sent: Thursday, October 21, 2021 9:52 AM
> To: Philippe Mathieu-Daudé <phi...@redhat.com>
> Cc: Sid Manning <sidn...@quicinc.com>; Marc-André Lureau
> <marcandre.lur...@redhat.com>; Paolo Bonzini <pbonz...@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é <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
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
