From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50444 invoked by alias); 18 May 2016 11:50:28 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 50433 invoked by uid 89); 18 May 2016 11:50:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Antoine, management, protect X-HELO: usplmg20.ericsson.net Received: from usplmg20.ericsson.net (HELO usplmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 18 May 2016 11:50:17 +0000 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id D9.F6.09012.9BE4C375; Wed, 18 May 2016 13:15:05 +0200 (CEST) Received: from elxa4wqvvz1 (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.96) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 18 May 2016 07:50:13 -0400 References: <1462530736-25117-1-git-send-email-yao.qi@linaro.org> <867ferajqb.fsf@gmail.com> User-agent: mu4e 0.9.17; emacs 24.4.1 From: Antoine Tremblay To: Yao Qi CC: Antoine Tremblay , Subject: Re: [RFC 0/3] Use reinsert breakpoint for vCont;s In-Reply-To: <867ferajqb.fsf@gmail.com> Date: Wed, 18 May 2016 11:50:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00294.txt.bz2 Yao Qi writes: > Antoine Tremblay 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.