This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 00/18] Remote all-stop on top of non-stop
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 19 Oct 2015 16:27:58 +0100
- Subject: Re: [PATCH 00/18] Remote all-stop on top of non-stop
- Authentication-results: sourceware.org; auth=none
- References: <1444836486-25679-1-git-send-email-palves at redhat dot com> <86lhb23gm4 dot fsf at gmail dot com> <86h9ln2i6x dot fsf at gmail dot com>
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