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

[Yao Qi <qiyaoltc at gmail dot com>]

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.

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

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

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

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

-- 
Yao (éå)