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 4/8] Force to insert software single step breakpoint


On 03/18/2016 02:24 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> Maybe what we need to do is firmly declare (and add comments in that
>> direction) that the arch's get_next_pcs implementation must always evaluate
>> the condition of conditional branches, and not put a breakpoint at the
>> branch destination if the condition is false, thus ensuring forward progress.
>> The ARM implementation does this, though I haven't checked whether all the
>> branch instructions are covered.  Some other archs don't, and always put
>> a break at the branch destination, like e.g., moxie_software_single_step.
> 
> Some targets doesn't evaluate condition and simply insert breakpoint on
> possible destinations.  They are cris, moxie, sparc and spu.  I'll add
> condition evaluation to these software single step implementations.
> 

Hmm, that is more work than I'd imagine you'd do.  I wasn't really thinking you'd
go hack those ports.  I'd be content with just adding the comment, and leaving the
ports be, being happy that we know about a path forward if necessary.

I think before my software single-step rework, these archs may already have had
this issue, as I think old gdb would insert the software single-step breakpoint in
this scenario.   We may not see it happen in practice on those archs, as I think
usually spinlock-style asm needs at least two instructions; one to load from an
address, another to conditionally branch.

>>
>> If we find some instruction where that is still not be sufficient,
>> due to side effects, then maybe gdb and gdbserver could first
>> try emulating the instruction's side effects manually.  And only
>> if that doesn't work, then try displaced stepping.  We could leave
>> that for later, until we find a need.
> 
> What does "that" mean in "We could leave that for later"?  Is it
> "instruction emulation + displaced stepping" or "displaced stepping"?

The whole "instruction emulation + displaced stepping".

> It is difficult to do instruction emulation for these targets, because I
> need to understand the details all these targets.  Just make sure I
> correctly understand the scope of the work.

Thanks,
Pedro Alves


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