[PATCH 8/9] Use reinsert_breakpoint for vCont;s

Pedro Alves palves@redhat.com
Fri Jul 1 15:07:00 GMT 2016


On 06/30/2016 03:09 PM, Yao Qi wrote:
> V3: - install breakpoints in proceed_one_lwp, if the thread doesn't have
>     reinsert breakpoints installed yet,
>     - no longer stop all threads when installing breakpoints,
>     - delete reinsert breakpoints when GDBserver wants to report event,
> 
>> - Also, if in all-stop mode, if gdb does:
>>
>> vCont;s:1;c
>>
>> thus setting thread 1 stepping, and all others continuing,
>> and then some other thread but thread 1 hits a breakpoint,
>> what is removing the reinsert breakpoint of thread 1?
> 
> if thread 1 doesn't hit the reinsert breakpoint, we don't have to
> remove them, because GDB will send vCont;s:1 next time, and GDBserver

There's no guarantee GDB will send vCont;s:1 next time.
The user may do "continue" instead of "step".

> can only install reinsert breakpoints if they are not installed yet.

The user may even do "return + continue" or "jump", or an infcall,
all of which resume the thread at a different address from the address
the thread last stopped.  So there's no guarantee that the
reinsert breakpoint address makes any sense for the next step request,
or even that the next resume request is a step in the first place.

Basically the previous step request must be completely forgotten after
gdb has seen the thread stop.  In all-stop, gdb "sees "all threads
stopped on each and every event reported to gdb, for any thread.
A stop reply cancels any and all previous resume requests.

> if thread hits the reinsert breakpoint, but the event is not reported.
> It becomes pending, and GDBserver will delete the reinsert breakpoints
> next time when this pending event is reported back to GDB.

I don't follow.  I'm talking about the case where the thread does _not_
hit the reinsert breakpoint.  Instead some other thread hits some unrelated
event.

Thanks,
Pedro Alves



More information about the Gdb-patches mailing list