This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 00/18] Remote all-stop on top of non-stop


Hi Yao,

Thanks for the investigation.

On 10/19/2015 12:47 PM, Yao Qi wrote:

> There are some ways fixing this problem,
> 
>  1. stop checking vCont;s packet anymore in range-stepping tests.
>  2. let gdbarch_displaced_step_hw_singlestep returns true for arm-linux
>  in the multi-arch case like this,
> 
> int
> arm_displaced_step_hw_singlestep (struct gdbarch *gdbarch,
> 				  struct displaced_step_closure *closure)
> {
>   if (target_can_do_single_step () == 1)
>     return 1;
> 
>   return 0;
> }
> then further, we need to either,
> 
>   2.1 teach GDB core to support single stepping multiple instructions in
>   scratch pad.  Nowadays, GDB only expects one stop event when executing
>   instructions in the scratchpad.  ARM is the only target that GDB
>   copies more than one instructions to the scratchpad, and resume
>   program there instead of single step.  Other targets, like x86,
>   aarch64, GDB only copies *one* instruction to the scratchpad and
>   single step.
>   2.2 rewrite arm displaced stepping code to be aware that the target
>   may be able to do single step, so that each time GDB has only to copy
>   one instruction to the scratchpad, do single step and fix up if necessary.
> 
> Fix #1 looks reasonable and ideal to me, and the easiest one.  Fix #2.1
> and #2.2 will need much work, at least #2.2, and I don't know how useful
> #2.1 is.
> 

Agreed, looks like #1 is the way to go.  #2.1 may even be counter
productive -- running to a breakpoint to skip multiple instructions at
once is likely faster than multiple hardware single-steps.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]