[PATCH] gdbserver gnu/linux: stepping over breakpoint

[Pedro Alves]

On 04/09/2015 04:24 PM, Pedro Alves wrote:
> On 04/09/2015 04:22 PM, Pedro Alves wrote:
>> On 04/09/2015 04:06 PM, Yao Qi wrote:
>>> Pedro Alves <palves@redhat.com> writes:
>>>
>>>> even reached.  The test isn't even threaded.  It sounds like
>>>> gdbserver is trying to step over the breakpoint at "foo"?  Didn't
>>>> gdb itself step over it?  How come that was reached in gdbserver?
>>>> Did we mishandle the breakpoint's reference count in gdbserver?
>>>
>>> Shouldn't GDBserver step over breakpoint when the target side condition
>>> is false?
>>
>> Oh, this is stepping past an hardware breakpoint, not software
>> breakpoint.  Yes, GDBserver should be stepping past such
>> breakpoints.  But, given GDBserver's software single-step
>> support is really really really really too simple:
>>
>> /* We only place breakpoints in empty marker functions, and thread locking
>>    is outside of the function.  So rather than importing software single-step,
>>    we can just run until exit.  */
>> static CORE_ADDR
>> arm_reinsert_addr (void)
>> {
>>   struct regcache *regcache = get_thread_regcache (current_thread, 1);
>>   unsigned long pc;
>>   collect_register_by_name (regcache, "lr", &pc);
>>   return pc;
>> }
>>
>> ... we should probably disable target side conditions on software
>> single-step gdbserver ports.  E.g., try "si" through this function:
> 
> Sorry, "si" probably works as gdb steps over the breakpoint
> itself.  Try "step" or "next" instead, which kick in the range
> stepping support, which then causes gdbserver to handle the
> step-over itself.

Hmm^2, no, range stepping couldn't possibly work correctly with
that limited software single-step support.  Duh.  We only
enable range stepping on x86, even.

So maybe that's "good enough" for stepping past conditional
breakpoints in practice.  Guess we should update the comments
to mention this.

Thanks,
Pedro Alves