This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC 0/3] Use reinsert breakpoint for vCont;s
- From: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: Antoine Tremblay <antoine dot tremblay at ericsson dot com>, <gdb-patches at sourceware dot org>
- Date: Wed, 18 May 2016 07:50:12 -0400
- Subject: Re: [RFC 0/3] Use reinsert breakpoint for vCont;s
- Authentication-results: sourceware.org; auth=none
- References: <1462530736-25117-1-git-send-email-yao dot qi at linaro dot org> <wwokfutg3hge dot fsf at ericsson dot com> <867ferajqb dot fsf at gmail dot 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.