From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LN8dP-0008G9-4W for qemu-devel@nongnu.org; Wed, 14 Jan 2009 11:30:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LN8dN-0008Du-6Q for qemu-devel@nongnu.org; Wed, 14 Jan 2009 11:30:26 -0500 Received: from [199.232.76.173] (port=42041 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LN8dM-0008De-TE for qemu-devel@nongnu.org; Wed, 14 Jan 2009 11:30:25 -0500 Received: from lizzard.sbs.de ([194.138.37.39]:19405) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LN8dM-0007KD-9Q for qemu-devel@nongnu.org; Wed, 14 Jan 2009 11:30:24 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n0EGUImA014533 for ; Wed, 14 Jan 2009 17:30:19 +0100 Received: from [139.25.109.167] (mchn012c.mchp.siemens.de [139.25.109.167] (may be forged)) by mail2.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n0EGUGcK022593 for ; Wed, 14 Jan 2009 17:30:18 +0100 Message-ID: <496E1319.9020901@siemens.com> Date: Wed, 14 Jan 2009 17:30:17 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <496DFA33.2020606@siemens.com> <58BD0469C48A7443A479A13D101685E301B3837B@ala-mail09.corp.ad.wrs.com> In-Reply-To: <58BD0469C48A7443A479A13D101685E301B3837B@ala-mail09.corp.ad.wrs.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RESEND][PATCH] gdbstub: Add vCont support Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Krumme, Chris wrote: > > >> -----Original Message----- >> From: >> qemu-devel-bounces+chris.krumme=windriver.com@nongnu.org >> [mailto:qemu-devel-bounces+chris.krumme=windriver.com@nongnu.o >> rg] On Behalf Of Jan Kiszka >> Sent: Wednesday, January 14, 2009 8:44 AM >> To: qemu-devel@nongnu.org >> Subject: [Qemu-devel] [RESEND][PATCH] gdbstub: Add vCont support >> >> [ Also available via git://git.kiszka.org/qemu.git queue/gdb ] >> >> In order to set the VCPU for the next single-step command, >> you need gdb >> 6.8 or better - and this patch. It enhances the existing support for >> representing VCPUs as threads to the gdb frontend by introducing the >> vCont remote gdb command. This is used by gdb to switch the debugging >> focus for single-stepping multi-threaded targets. >> >> Signed-off-by: Jan Kiszka >> --- >> >> gdbstub.c | 56 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 56 insertions(+), 0 deletions(-) >> >> diff --git a/gdbstub.c b/gdbstub.c >> index 0bcd5d5..1cb20b7 100644 >> --- a/gdbstub.c >> +++ b/gdbstub.c >> @@ -1542,6 +1542,62 @@ static int gdb_handle_packet(GDBState >> *s, const char *line_buf) >> s->signal = 0; >> gdb_continue(s); >> return RS_IDLE; >> + case 'v': >> + if (strncmp(p, "Cont", 4) == 0) { >> + int res_signal, res_thread; >> + >> + p += 4; >> + if (*p == '?') { >> + put_packet(s, "vCont;c;C;s;S"); >> + break; >> + } >> + res = 0; >> + res_signal = 0; >> + res_thread = 0; >> + while (*p) { >> + int action, signal; >> + >> + if (*p++ != ';') { >> + res = 0; >> + break; >> + } >> + action = *p++; >> + signal = 0; >> + if (action == 'C' || action == 'S') >> + signal = strtoul(p, (char **)&p, 16); >> + else if (action != 'c' && action != 's') { >> + res = 0; >> + break; >> + } >> + thread = 0; >> + if (*p == ':') >> + thread = strtoull(p+1, (char **)&p, 16); >> + >> + action = tolower(action); >> + if (res == 0 || (res == 'c' && action == 's')) { >> + res = action; >> + res_signal = signal; >> + res_thread = thread; >> + } >> + } >> + if (res) { >> + if (res_thread != -1 && res_thread != 0) { >> + for (env = first_cpu; env != NULL; env = >> env->next_cpu) >> + if (env->cpu_index + 1 == res_thread) >> + break; >> + if (env == NULL) { >> + put_packet(s, "E22"); >> + break; >> + } >> + s->c_cpu = env; >> + } >> + if (res == 's') >> + cpu_single_step(s->c_cpu, sstep_flags); >> + gdb_continue(s); > > Where did res_signal go? Good question... Looks like I forgot some 's->signal = res_signal;' here. Will add this. > (btw: some OS use signal 0 along with the > rest.) In case of the 'c' command, gdbstub also sets s->signal to 0, so I don't think this default value can be problematic. > >> + return RS_IDLE; >> + } > > If the command is not vCont do you need to return an error? True, this screams for 'goto unknown_command;' Thanks for reviewing! Jan -- Siemens AG, Corporate Technology, CT SE 26 Corporate Competence Center Embedded Linux