From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gR1rE-0003ZR-Te for qemu-devel@nongnu.org; Sun, 25 Nov 2018 16:22:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gR1rB-0007Io-L3 for qemu-devel@nongnu.org; Sun, 25 Nov 2018 16:22:24 -0500 Received: from mail-wm1-f67.google.com ([209.85.128.67]:36073) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gR1rB-0007IU-Em for qemu-devel@nongnu.org; Sun, 25 Nov 2018 16:22:21 -0500 Received: by mail-wm1-f67.google.com with SMTP id s11so16417145wmh.1 for ; Sun, 25 Nov 2018 13:22:21 -0800 (PST) References: <20181123091729.29921-1-luc.michel@greensocs.com> <20181123091729.29921-4-luc.michel@greensocs.com> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Message-ID: <970cc3ab-f93b-75c2-f3f0-86a1ddc75ca7@redhat.com> Date: Sun, 25 Nov 2018 22:22:17 +0100 MIME-Version: 1.0 In-Reply-To: <20181123091729.29921-4-luc.michel@greensocs.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v7 03/16] gdbstub: add multiprocess support to '?' packets List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luc Michel , qemu-devel@nongnu.org Cc: Peter Maydell , Eduardo Habkost , alistair@alistair23.me, mark.burton@greensocs.com, =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , saipava@xilinx.com, edgari@xilinx.com, qemu-arm@nongnu.org Hi Luc, On 23/11/18 10:17, Luc Michel wrote: > The gdb_get_cpu_pid() function does the PID lookup for the given CPU. It > checks if the CPU is a direct child of a CPU cluster. If it is, the > returned PID is the cluster ID plus one (cluster IDs start at 0, GDB > PIDs at 1). When the CPU is not a child of such a container, the PID of > the first process is returned. > > The gdb_fmt_thread_id() function generates the string to be used to identify > a given thread, in a response packet for the peer. This function > supports generating thread IDs when multiprocess mode is enabled (in the > form `p.'). > > Use them in the reply to a '?' request. > > Signed-off-by: Luc Michel > Acked-by: Alistair Francis > Reviewed-by: Edgar E. Iglesias > --- > gdbstub.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 58 insertions(+), 2 deletions(-) > > diff --git a/gdbstub.c b/gdbstub.c > index 26f5a7449a..4fbc05dfe3 100644 > --- a/gdbstub.c > +++ b/gdbstub.c > @@ -638,10 +638,52 @@ static int memtox(char *buf, const char *mem, int len) > } > } > return p - buf; > } > > +static uint32_t gdb_get_cpu_pid(const GDBState *s, CPUState *cpu) > +{ > +#ifndef CONFIG_USER_ONLY > + gchar *path, *name; Setting ... gchar *path, *name = NULL; > + Object *obj; > + CPUClusterState *cluster; > + uint32_t ret; > + > + path = object_get_canonical_path(OBJECT(cpu)); > + name = object_get_canonical_path_component(OBJECT(cpu)); ... we might move this line ... > + > + if (path == NULL) { > + ret = s->processes[0].pid; > + goto out; > + } ... here: name = object_get_canonical_path_component(OBJECT(cpu)); > + > + /* > + * Retrieve the CPU parent path by removing the last '/' and the CPU name > + * from the CPU canonical path. */ > + path[strlen(path) - strlen(name) - 1] = '\0'; Can we get there with path != NULL && name == NULL? > + > + obj = object_resolve_path_type(path, TYPE_CPU_CLUSTER, NULL); > + > + if (obj == NULL) { > + ret = s->processes[0].pid; > + goto out; > + } > + > + cluster = CPU_CLUSTER(obj); > + ret = cluster->cluster_id + 1; > + > +out: > + g_free(name); > + g_free(path); > + > + return ret; > + > +#else [*] > + return s->processes[0].pid; > +#endif > +} > + > static const char *get_feature_xml(const char *p, const char **newp, > CPUClass *cc) > { > size_t len; > int i; > @@ -907,10 +949,23 @@ static CPUState *find_cpu(uint32_t thread_id) > } > > return NULL; > } > > +static char *gdb_fmt_thread_id(const GDBState *s, CPUState *cpu, > + char *buf, size_t buf_size) > +{ > + if (s->multiprocess) { > + snprintf(buf, buf_size, "p%02x.%02x", > + gdb_get_cpu_pid(s, cpu), cpu_gdb_index(cpu)); > + } else { > + snprintf(buf, buf_size, "%02x", cpu_gdb_index(cpu)); > + } > + > + return buf; > +} > + > static int is_query_packet(const char *p, const char *query, char separator) > { > unsigned int query_len = strlen(query); > > return strncmp(p, query, query_len) == 0 && > @@ -1018,22 +1073,23 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf) > const char *p; > uint32_t thread; > int ch, reg_size, type, res; > uint8_t mem_buf[MAX_PACKET_LENGTH]; > char buf[sizeof(mem_buf) + 1 /* trailing NUL */]; > + char thread_id[16]; > uint8_t *registers; > target_ulong addr, len; > > trace_gdbstub_io_command(line_buf); > > p = line_buf; > ch = *p++; > switch(ch) { > case '?': > /* TODO: Make this return the correct value for user-mode. */ Is this comment still relevant? If so, wouldn't it be better placed in [*]? > - snprintf(buf, sizeof(buf), "T%02xthread:%02x;", GDB_SIGNAL_TRAP, > - cpu_gdb_index(s->c_cpu)); > + snprintf(buf, sizeof(buf), "T%02xthread:%s;", GDB_SIGNAL_TRAP, > + gdb_fmt_thread_id(s, s->c_cpu, thread_id, sizeof(thread_id))); > put_packet(s, buf); > /* Remove all the breakpoints when this query is issued, > * because gdb is doing and initial connect and the state > * should be cleaned up. > */ >