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

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

Pedro Alves writes:

> On 01/30/2017 01:28 PM, Antoine Tremblay wrote:
>
>>> We don't change anything when setting breakpoint inside IT block.
>>
>> Well that's a problem if we write a 32 bit thumb2 breakpoint aligned on
>> 2 bytes like discussed before.
>

Sorry for the delay I just saw your mail...

> Can we restrict the stopping-all-threads to the case that
> needs it, only?

Possibly but I would like to avoid introducing 2 execution paths in the
run control, it's already hard to follow as it is and it would introduce
a lot of code in the arch independant code just for this case, that's
something I would like to avoid too.

>
> An optimization that would avoid this would be to use a
> hardware watchpoint/breakpoint (if available) for single-stepping.
> IIRC, you can ARM a breakpoint (or was it a watchpoint) on ARM for
> triggering when the PC is different from the current PC (or really,
> some specified address).

I did not know that but I'm worried about the limited number of hardware
watchpoints available. IIRC on my board I had only 4, if GDBServer can't
find one available would it refuse to single step ? That would be
weird... ?

It's an interesting approch however I'll dig about it more.

>
> In IT blocks, this would probably make the thread stop on
> instructions that aren't really executed (e.g., the then/else
> branches when the condition is correspondingly false/true),

Really ? I need to find something about that in the arch man...

> unlike the current solution where breakpoint instructions are
> not executed by the CPU when it falls on an instruction that
> isn't executed (because the breakpoint opcode we use it just
> some magic invalid instruction, node the BKPT instruction), but
> I think that when the thread stops, and we're stepping an IT
> block, we could look at the status registers and decide whether
> to single-step again.
>
> TBC, I'm not suggesting that we need to do that right now.
>
> The emulation solution discussed on the lkml thread made
> me thing of displaced stepping -- the ARM implementation
> emulates some instructions.  I wonder whether displaced
> stepping over IT blocks is already handled correctly.
>

It does look like displaced stepping would be preferable to trying to
emulate and validate that the emulation is correct.

Simon and I are looking into displaced stepping but we've yet to have
this discussion with Yao...