Re: [RFC 0/3] Use reinsert breakpoint for vCont;s

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

Yao Qi writes:

> Antoine Tremblay <antoine.tremblay@ericsson.com> writes:
>
>> I think like you did in patch 2 before we know we're reporting to GDB
>> the right place too, but adding a
>> prepare_to_access_memory/done_accessing_memory lock around the delete /
>> insert reinsert breakpoints is needed.
>
> prepare_to_access_memory and done_accessing_memory are used when *GDB*
> wants to access memory, not GDBserver.
>
Yes I know, I don't see what prevents us to extend it to GDBServer to
protect non-stop operations however ?

>>
>> Actually pretty much the only thing that single step reinsert breakpoints have
>> in common with step over reinsert breakpoints is that they're
>> inserted as a GDBServer breakpoint. No other code path is the same, afaick.
>>
>
> They use the_low_target.get_next_pcs to know the next pcs.
>

Right, good point.

>> I think it would be more clear to have a different kind of breakpoint so that :
>>
>>  - We can protect these breakpoints with prepare_to_access_memory
>>  without affecting the step over reinsert breakpoints, that do not need this.
>
> prepare_to_access_memory can't be used here, because it is "prepare for
> the memory access requested by GDB".
>

Same question as above...

>>  - Have these breakpoints thread specific, again something that
>>  step-over breakpoints do not need.
>
> Nowadays, we do step-over once per thread, so it is not harmful to make
> reinsert breakpoint thread specific.
>
>>
>> The added logic to the control flow should be about the same or less
>> than by sharing the reinsert_breakpoints.
>>
>> Also, when changing code related to either of the 2 scenarios we would not
>> fear breaking one or the other. Things are already mangled enough
>> in that area ?
>
> I don't think we can deal with the control flow or logic separately,
> because we add breakpoint for vCont;s, and breakpoint and event
> management should be done in linux_wait_1 and linux_resume.  Adding a
> new kind of breakpoint doesn't help, IMO.
>
OK.

> I've got a regression-free patch series, but need to remove some
> redundant code, and post the out for review.

OK thanks, I'll wait for that.