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 1/2] This patch fixes GDBServer's run control for single stepping


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.

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

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

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

Thanks,
Pedro Alves


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