This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] This patch fixes GDBServer's run control for single stepping
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 27 Jan 2017 17:00:57 +0000
- Subject: Re: [PATCH 1/2] This patch fixes GDBServer's run control for single stepping
- Authentication-results: sourceware.org; auth=none
- References: <20161129120702.9490-1-antoine.tremblay@ericsson.com> <20170127150139.GB24676@E107787-LIN> <wwokwpdg5vxa.fsf@ericsson.com>
On Fri, Jan 27, 2017 at 4:06 PM, Antoine Tremblay
<antoine.tremblay@ericsson.com> wrote:
>> GDB/GDBserver has to emulate the instruction on how does it affect the
>> flag, and only insert the breakpoint on the "true" branch. Since the
>> target instruction will be definitely executed, we can safely use
>> 16-bit breakpoint instruction.
>
> Ouch, reading the kernel thread it looks like this emulation would be
> complex to say the least.
>
There are some other ideas discussed in the kernel threads, but I didn't
go through them. They may work. If emulation is complex, probably
we can partially fix this problem by "always using 16-bit thumb instruction
if program is out of IT block".
> I think it would be better to get the current single stepping working
> with the stop all threads logic since GDBServer was working like that
> when GDB was doing the single stepping anyway. This would fix the current
> regression.
>
> Then work could be done to improve GDBServer to be better at
> non-stopping.
>
> WDYT ?
>
Sounds like we are applying the ARM linux limitation to a general place.
Other software single step targets may write breakpoint in atomic way,
so we don't need to stop all threads. Even in -marm mode, we don't
have to stop all threads on inserting breakpoints.
--
Yao (齐尧)