gdbstub: fix sThreadInfo handler
PATCH 1/1 gdbstub: fix sThreadInfo handler
After the commit 182735e cpu: Make first_cpu and next_cpu CPUState we can no longer blindly use cpu->next_cpu->env_ptr to get CPUArchState of the next CPU, as the next_cpu is NULL in the last CPU.
This fixes segfault caused by gdb command 'info threads'.
--- gdbstub.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)
gdbstub.c +3 -2
@@ -2406,10 +2406,11 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf) }else if (strcmp (p,"sThreadInfo" ) ==0 ) { report_cpuinfo:if (s->query_cpu) { +CPUState *cpu =ENV_GET_CPU (s->query_cpu);snprintf (buf,sizeof (buf),"m%x" , -cpu_index (ENV_GET_CPU (s->query_cpu))); +cpu_index (cpu));put_packet (s, buf); - s->query_cpu =ENV_GET_CPU (s->query_cpu)->next_cpu->env_ptr; + s->query_cpu = cpu->next_cpu ? cpu->next_cpu->env_ptr :NULL ; }else put_packet (s,"l" );break ;
Signature · 1 line
1.7.7.6
Am 22.07.2013 07:24, schrieb Max Filippov:
Quoted 7 lines
After the commit 182735e cpu: Make
first_cpuandnext_cpuCPUState we can no longer blindly usecpu->next_cpu->env_ptrto get CPUArchState of the next CPU, as thenext_cpuis NULL in the last CPU.This fixes segfault caused by gdb command 'info threads'.
Signed-off-by Max Filippov <[email protected]>
This should be obsoleted by the patch on qom-cpu that I pointed you to, no? I so far didn't send a pull for that alone since I was hoping to get more gdbstub patches in - I added a comment explaining vaddr type as requested by Peter, so a Reviewed-by/Acked-by for the modified Xtensa subclasses would help push that forward, and no one bothered to review the ..._read_register() changes yet IIRC, split up on rth's request. I could just apply the initial set_pc stuff of course and wait some longer with the rest.
Andreas
Quoted 23 lines
--- gdbstub.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-)gdbstub.c +3
-2@@ -2406,10 +2406,11 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf) }else if (strcmp (p,"sThreadInfo" ) ==0 ) { report_cpuinfo:if (s->query_cpu) { +CPUState *cpu =ENV_GET_CPU (s->query_cpu);snprintf (buf,sizeof (buf),"m%x" , -cpu_index (ENV_GET_CPU (s->query_cpu))); +cpu_index (cpu));put_packet (s, buf); - s->query_cpu =ENV_GET_CPU (s->query_cpu)->next_cpu->env_ptr; + s->query_cpu = cpu->next_cpu ? cpu->next_cpu->env_ptr :NULL ; }else put_packet (s,"l" );break ;
Signature · 2 lines
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Quoted 5 lines · Andreas Färber
Am 22.07.2013 07:24, schrieb Max Filippov:
Quoted 4 lines
After the commit 182735e cpu: Make
first_cpuandnext_cpuCPUState we can no longer blindly usecpu->next_cpu->env_ptrto get CPUArchState of the next CPU, as thenext_cpuis NULL in the last CPU.
Quoted 7 lines
Quoted 3 lines
This fixes segfault caused by gdb command 'info threads'.
Signed-off-by Max Filippov <[email protected]>This should be obsoleted by the patch on qom-cpu that I pointed you to, no? I so far didn't send a pull for that alone since I was hoping to get more gdbstub patches in - I added a comment explaining vaddr type as
I've noticed that the other gdbstub fix is in, but debugging is still broken in the mainline. In fact it had been broken just a few commits after that fix, in the same pull request.
Holding a fix in order to make a bigger pull request later is not the right thing IMHO.
Quoted 2 lines
requested by Peter, so a Reviewed-by/Acked-by for the modified Xtensa subclasses would help push that forward, and no one bothered to review
Ok, I will review it.
Quoted 3 lines
the ..._read_register() changes yet IIRC, split up on rth's request. I could just apply the initial
set_pcstuff of course and wait some longer with the rest.
Signature · 2 lines
Thanks. -- Max