Re: [PATCH 1/2] This patch fixes GDBServer's run control for single stepping

[Antoine Tremblay <antoine.tremblay@ericsson.com>]

Yao Qi writes:

> 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.

There was this one
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-January/007515.html

But it got discarded: http://lists.infradead.org/pipermail/linux-arm-kernel/2010-January/007517.html

> 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 would be against that since it would leave the feature partially
working and crashing the program when it fails...

It would also be a regression compared to previous GDBServer.
Also, IT blocks are a common place to have a breakpoint/tracepoint.

>> 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.

Well ARM is the only software single stepping target, while I agreee
that we would be affecting general code, I think that since there is
no software single step breakpoint target that supports atomic
breakpoint writes at the moment it's normal that the run control
doesn't support that.

I don't count -marm as an arch since there no way to check that all the
program including shared libs etc is -marm, I don't think we could make
the distinction in GDBServer AFAIK.

Should an arch support this in the future we could adapt the run control
to support both cases possibly via some arch specific property.

I think also that given the current trends in architecture design the
odds of another arch needing that in the future are also unlikely ?

WDYT ?