[RFC 0/3] Use reinsert breakpoint for vCont;s
Yao Qi
qiyaoltc@gmail.com
Wed May 18 07:50:00 GMT 2016
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 (齐尧)
More information about the Gdb-patches
mailing list