[Qemu-devel] qemu-user/gdbstub : gdb remote pipe connexion addition ?

[Qemu-devel] qemu-user/gdbstub : gdb remote pipe connexion addition ?

[Philippe Waille]

Hi

Qemu gdbstub only allows GDB remote target connexion through IP socket.

Would the GDB remote pipe connexion method be also supported in future versions
(as does openocd for remote access to jtag interfaces), like this :

(gdb) target remote | exec openocd --pipe
(gdb) target remote | exec qemu-arm --pipe a.out

Simultaneous execution of several (user-mode arm simulators) qemu-arm by a 
set of users sharing a single server would be easier to manage with 
gdb connexion through pipes instead of IP port/socket.

Ph. W.
-- 
-----------------------------------------------------------------------------
Philippe WAILLE                            email :    Philippe.Waille@imag.fr
IMAG ID (Informatique et distribution)       Tel :    04 76 61 20 13
ENSIMAG - antenne de Montbonnot          Foreign :  33 4 76 61 20 13
INOVALLEE					     Fax :    04 76 61 20 99
51, avenue Jean Kuntzmann
38330 MONTBONNOT SAINT MARTIN

[Qemu-devel] Re: qemu-user/gdbstub : gdb remote pipe connexion addition ?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]

Philippe Waille wrote:
> Hi
> 
> Qemu gdbstub only allows GDB remote target connexion through IP socket.
> 
> Would the GDB remote pipe connexion method be also supported in future versions
> (as does openocd for remote access to jtag interfaces), like this :
> 
> (gdb) target remote | exec openocd --pipe
> (gdb) target remote | exec qemu-arm --pipe a.out
> 
> Simultaneous execution of several (user-mode arm simulators) qemu-arm by a 
> set of users sharing a single server would be easier to manage with 
> gdb connexion through pipes instead of IP port/socket.

Check out [1]. It basically enhances qemu like that (the corresponding
switch would be '-gdb stdio'), but only for system emulation. An add-on
patch to extend user mode emulator in a similar way would be welcome!

There is one more thing to solve for both emulator modes: SIGINT has to
be trapped and handled by the gdbstub (currently, breaking into the
target terminates qemu). These hunks do the trick for system emulation:

diff --git a/gdbstub.c b/gdbstub.c
index a087553..1f43264 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -2446,6 +2446,14 @@ static int gdb_monitor_write(CharDriverState *chr, const uint8_t *buf, int len)
     return len;
 }
 
+#ifndef _WIN32
+static void gdb_sigterm_handler(int signal)
+{
+    if (vm_running)
+        vm_stop(EXCP_INTERRUPT);
+}
+#endif
+
 int gdbserver_start(const char *device)
 {
     GDBState *s;
@@ -2462,7 +2470,15 @@ int gdbserver_start(const char *device)
                      "%s,nowait,nodelay,server", device);
             device = gdbstub_device_name;
         }
+#ifndef _WIN32
+        else if (strcmp(device, "stdio") == 0) {
+            struct sigaction act;
 
+            memset(&act, 0, sizeof(act));
+            act.sa_handler = gdb_sigterm_handler;
+            sigaction(SIGINT, &act, NULL);
+        }
+#endif
         chr = qemu_chr_open("gdb", device, NULL);
         if (!chr)
             return -1;

Will merge this into some -v2 of my patch.

Jan

[1] http://permalink.gmane.org/gmane.comp.emulators.qemu/39836


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] qemu-user/gdbstub : gdb remote pipe connexion addition ?

[Paul Brook]

> Qemu gdbstub only allows GDB remote target connexion through IP socket.

Actually that's not true.

System emulation it can talk to stdio.

For userspace emulation using stdio IMHO doesn't make a whole lot of sense. 
The user application is almost certainly already using that for something 
else. This is different to e.g. gdbserver and openocd where the debug stub is 
a separate process from the user application.

Paul

Re: [Qemu-devel] qemu-user/gdbstub : gdb remote pipe connexion addition ?

[Philippe Waille]

On Tue, Mar 24, 2009 at 12:52:57PM +0000, Paul Brook wrote:
> For userspace emulation using stdio IMHO doesn't make a whole lot of sense. 
> The user application is almost certainly already using that for something 
> else. This is different to e.g. gdbserver and openocd where the debug stub is 
> a separate process from the user application.

Ok if qemu in user mode only targets cross develop/debug/benchmark of 
complete applications in C/C++/JAVA/... for an embeded target system. But I
consider other another usage. 

An efficient user mode simulator such as qemu is also very interesting for 
(any ISA != IA32) assembly langage teaching. I  would use it to replace the 
gdb builtin ARM simulator (rdi targeti, removed from gdb since 6.4). 

Students learning assembly langage programming ususally write very 
small programs (n!, sum of array elements,...) and will only use a few basic
stdio primitives (printf/scanf/putchar/getchar) already translated in gdb 
remote file I/O by qemu gbstub. Nothing else : they don't call pipe, dup
or ioctl from assembler code !

Qemu-arm user mode with socket based gdb connexion is already a valuable tool, 
but gdb remote pipe connexion would allow cleaner and easier 
gdb starting/configuration/termination procedures (script files),
especially on shared POSIX servers.

Note : I would event be interested by ARM semihosting on gdb file I/O 
protocol through openocd and JTAG interfaces, ... but its too
much work for the benefits.

Best regards
Ph. W.

-- 
-----------------------------------------------------------------------------
Philippe WAILLE                            email :    Philippe.Waille@imag.fr
IMAG ID (Informatique et distribution)       Tel :    04 76 61 20 13
ENSIMAG - antenne de Montbonnot          Foreign :  33 4 76 61 20 13
INOVALLEE					     Fax :    04 76 61 20 99
51, avenue Jean Kuntzmann
38330 MONTBONNOT SAINT MARTIN