| Message ID | 20161209124625.31861-1-antoine.tremblay@ericsson.com |
|---|---|
| State | New |
| Headers | show |
Ping. (Sorry I had a mistake in Yao's email on 1st post) Antoine Tremblay writes: > In this v3: > * Stack reads are now done with ->read_memory > * Note tha this invalidated PATH 3/3 about sparc, since it's also a read from stack.. > > Before this patch, some functions would read the inferior memory with > (*the_target)->read_memory, which returns the raw memory, rather than the > shadowed memory. > > This is wrong since these functions do not expect to read a breakpoint > instruction and can lead to invalid behavior. > > Use of raw memory in get_next_pcs_read_memory_unsigned_integer for example > could lead to get_next_pc returning an invalid pc. > > Here's how this would happen: > > In non-stop: > > the user issues: > > thread 1 > step& > thread 2 > step& > thread 3 > step& > > In a similar way as non-stop-fair-events.exp (threads are looping). > > GDBServer: > > linux_resume is called > GDBServer has pending events, > threads are not resumed and single-step breakpoint for thread 1 not installed. > > linux_wait_1 is called with a pending event on thread 2 at pc A > GDBServer handles the event and calls proceed_all_lwps > This calls proceed_one_lwp and installs single-step breakpoints on all > the threads that need one. > > Now since thread 1 needs to install a single-step breakpoint and is at pc B > (different than thread 2), a step-over is not initiated and get_next_pc > is called to figure out the next instruction from pc B. > > However it may just be that thread 3 as a single step breakpoint at pc > B. And thus get_next_pc fails. > > This situation is tested with non-stop-fair-events.exp. > > In other words, single-step breakpoints are installed in proceed_one_lwp > for each thread. GDBserver proceeds two threads for resume_step, as > requested by GDB, and the thread proceeded later may see the single-step > breakpoints installed for the thread proceeded just now. > > Tested on gdbserver-native/-m{thumb,arm} no regressions. > > gdb/gdbserver/ChangeLog: > > * linux-aarch32-low.c (arm_breakpoint_kind_from_pc): Use > target_read_memory. > * linux-arm-low.c (get_next_pcs_read_memory_unsigned_integer): Likewise. > (get_next_pcs_syscall_next_pc): Likewise. > --- > gdb/gdbserver/linux-aarch32-low.c | 4 ++-- > gdb/gdbserver/linux-arm-low.c | 5 +++-- > 2 files changed, 5 insertions(+), 4 deletions(-) > > diff --git a/gdb/gdbserver/linux-aarch32-low.c b/gdb/gdbserver/linux-aarch32-low.c > index 5547cf6491..4ff34b626b 100644 > --- a/gdb/gdbserver/linux-aarch32-low.c > +++ b/gdb/gdbserver/linux-aarch32-low.c > @@ -237,11 +237,11 @@ arm_breakpoint_kind_from_pc (CORE_ADDR *pcptr) > *pcptr = UNMAKE_THUMB_ADDR (*pcptr); > > /* Check whether we are replacing a thumb2 32-bit instruction. */ > - if ((*the_target->read_memory) (*pcptr, buf, 2) == 0) > + if (target_read_memory (*pcptr, buf, 2) == 0) > { > unsigned short inst1 = 0; > > - (*the_target->read_memory) (*pcptr, (gdb_byte *) &inst1, 2); > + target_read_memory (*pcptr, (gdb_byte *) &inst1, 2); > if (thumb_insn_size (inst1) == 4) > return ARM_BP_KIND_THUMB2; > } > diff --git a/gdb/gdbserver/linux-arm-low.c b/gdb/gdbserver/linux-arm-low.c > index ed9b3562a8..930cc34f71 100644 > --- a/gdb/gdbserver/linux-arm-low.c > +++ b/gdb/gdbserver/linux-arm-low.c > @@ -263,7 +263,8 @@ get_next_pcs_read_memory_unsigned_integer (CORE_ADDR memaddr, > ULONGEST res; > > res = 0; > - (*the_target->read_memory) (memaddr, (unsigned char *) &res, len); > + target_read_memory (memaddr, (unsigned char *) &res, len); > + > return res; > } > > @@ -804,7 +805,7 @@ get_next_pcs_syscall_next_pc (struct arm_get_next_pcs *self) > unsigned long this_instr; > unsigned long svc_operand; > > - (*the_target->read_memory) (pc, (unsigned char *) &this_instr, 4); > + target_read_memory (pc, (unsigned char *) &this_instr, 4); > svc_operand = (0x00ffffff & this_instr); > > if (svc_operand) /* OABI. */
On 16-12-09 07:46:25, Antoine Tremblay wrote: > > This situation is tested with non-stop-fair-events.exp. > > In other words, single-step breakpoints are installed in proceed_one_lwp > for each thread. GDBserver proceeds two threads for resume_step, as > requested by GDB, and the thread proceeded later may see the single-step > breakpoints installed for the thread proceeded just now. > > Tested on gdbserver-native/-m{thumb,arm} no regressions. I assume this patch fixes fails in non-stop-fair-events.exp. > > gdb/gdbserver/ChangeLog: > > * linux-aarch32-low.c (arm_breakpoint_kind_from_pc): Use > target_read_memory. > * linux-arm-low.c (get_next_pcs_read_memory_unsigned_integer): Likewise. > (get_next_pcs_syscall_next_pc): Likewise. Patch is good to me.
Yao Qi writes: > On 16-12-09 07:46:25, Antoine Tremblay wrote: >> >> This situation is tested with non-stop-fair-events.exp. >> >> In other words, single-step breakpoints are installed in proceed_one_lwp >> for each thread. GDBserver proceeds two threads for resume_step, as >> requested by GDB, and the thread proceeded later may see the single-step >> breakpoints installed for the thread proceeded just now. >> >> Tested on gdbserver-native/-m{thumb,arm} no regressions. > > I assume this patch fixes fails in non-stop-fair-events.exp. No, it helps but fails are still present, to fix things you need https://sourceware.org/ml/gdb-patches/2016-11/msg00939.html and https://sourceware.org/ml/gdb-patches/2016-11/msg00940.html If you can take a look at those too it would be nice ? > >> >> gdb/gdbserver/ChangeLog: >> >> * linux-aarch32-low.c (arm_breakpoint_kind_from_pc): Use >> target_read_memory. >> * linux-arm-low.c (get_next_pcs_read_memory_unsigned_integer): Likewise. >> (get_next_pcs_syscall_next_pc): Likewise. > > Patch is good to me. Patch is pushed in.
diff --git a/gdb/gdbserver/linux-aarch32-low.c b/gdb/gdbserver/linux-aarch32-low.c index 5547cf6491..4ff34b626b 100644 --- a/gdb/gdbserver/linux-aarch32-low.c +++ b/gdb/gdbserver/linux-aarch32-low.c @@ -237,11 +237,11 @@ arm_breakpoint_kind_from_pc (CORE_ADDR *pcptr) *pcptr = UNMAKE_THUMB_ADDR (*pcptr); /* Check whether we are replacing a thumb2 32-bit instruction. */ - if ((*the_target->read_memory) (*pcptr, buf, 2) == 0) + if (target_read_memory (*pcptr, buf, 2) == 0) { unsigned short inst1 = 0; - (*the_target->read_memory) (*pcptr, (gdb_byte *) &inst1, 2); + target_read_memory (*pcptr, (gdb_byte *) &inst1, 2); if (thumb_insn_size (inst1) == 4) return ARM_BP_KIND_THUMB2; } diff --git a/gdb/gdbserver/linux-arm-low.c b/gdb/gdbserver/linux-arm-low.c index ed9b3562a8..930cc34f71 100644 --- a/gdb/gdbserver/linux-arm-low.c +++ b/gdb/gdbserver/linux-arm-low.c @@ -263,7 +263,8 @@ get_next_pcs_read_memory_unsigned_integer (CORE_ADDR memaddr, ULONGEST res; res = 0; - (*the_target->read_memory) (memaddr, (unsigned char *) &res, len); + target_read_memory (memaddr, (unsigned char *) &res, len); + return res; } @@ -804,7 +805,7 @@ get_next_pcs_syscall_next_pc (struct arm_get_next_pcs *self) unsigned long this_instr; unsigned long svc_operand; - (*the_target->read_memory) (pc, (unsigned char *) &this_instr, 4); + target_read_memory (pc, (unsigned char *) &this_instr, 4); svc_operand = (0x00ffffff & this_instr); if (svc_operand) /* OABI. */
In this v3: * Stack reads are now done with ->read_memory * Note tha this invalidated PATH 3/3 about sparc, since it's also a read from stack.. Before this patch, some functions would read the inferior memory with (*the_target)->read_memory, which returns the raw memory, rather than the shadowed memory. This is wrong since these functions do not expect to read a breakpoint instruction and can lead to invalid behavior. Use of raw memory in get_next_pcs_read_memory_unsigned_integer for example could lead to get_next_pc returning an invalid pc. Here's how this would happen: In non-stop: the user issues: thread 1 step& thread 2 step& thread 3 step& In a similar way as non-stop-fair-events.exp (threads are looping). GDBServer: linux_resume is called GDBServer has pending events, threads are not resumed and single-step breakpoint for thread 1 not installed. linux_wait_1 is called with a pending event on thread 2 at pc A GDBServer handles the event and calls proceed_all_lwps This calls proceed_one_lwp and installs single-step breakpoints on all the threads that need one. Now since thread 1 needs to install a single-step breakpoint and is at pc B (different than thread 2), a step-over is not initiated and get_next_pc is called to figure out the next instruction from pc B. However it may just be that thread 3 as a single step breakpoint at pc B. And thus get_next_pc fails. This situation is tested with non-stop-fair-events.exp. In other words, single-step breakpoints are installed in proceed_one_lwp for each thread. GDBserver proceeds two threads for resume_step, as requested by GDB, and the thread proceeded later may see the single-step breakpoints installed for the thread proceeded just now. Tested on gdbserver-native/-m{thumb,arm} no regressions. gdb/gdbserver/ChangeLog: * linux-aarch32-low.c (arm_breakpoint_kind_from_pc): Use target_read_memory. * linux-arm-low.c (get_next_pcs_read_memory_unsigned_integer): Likewise. (get_next_pcs_syscall_next_pc): Likewise. --- gdb/gdbserver/linux-aarch32-low.c | 4 ++-- gdb/gdbserver/linux-arm-low.c | 5 +++-- 2 files changed, 5 insertions(+), 4 deletions(-)