From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87711 invoked by alias); 9 May 2016 15:17:53 -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 87686 invoked by uid 89); 9 May 2016 15:17:51 -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=H*r:0400, Suppose, Hx-languages-length:4606, HX-Envelope-From:sk:antoine 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; Mon, 09 May 2016 15:17:41 +0000 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id B0.FB.09012.442A0375; Mon, 9 May 2016 16:44:20 +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; Mon, 9 May 2016 11:17:38 -0400 References: <1462530736-25117-1-git-send-email-yao.qi@linaro.org> User-agent: mu4e 0.9.17; emacs 24.4.1 From: Antoine Tremblay To: Yao Qi CC: Subject: Re: [RFC 0/3] Use reinsert breakpoint for vCont;s In-Reply-To: <1462530736-25117-1-git-send-email-yao.qi@linaro.org> Date: Mon, 09 May 2016 15:17:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00148.txt.bz2 Yao Qi writes: > Nowadays, reinsert breakpoint is used in GDBserver to step over a > breakpoint. I want to use it to handle vCont;s. The motivation > of this work is to exercise software single step in GDBserver side. > In the past two weeks, I am fixing various test fails, but still > can't fix all of them. I want to post something here, and hope > people can help me on this area. > > Suppose GDB is able to send vCont;s to GDBserver using software > single step (done by patch 3), what should GDBserver do? It call > function single_step if lwp->resume->kind is resume_step. See > patch 2. > > With this change, reinsert breakpoint is used for two purposes, > 1) step over GDBserver breakpoint, 2) handle vCont;s. Here are some > facts or assumptions in my mind, > > - reinsert breakpoints can be inserted for both step over and > vCont;s together. GDBserver should finish all step-overs > before resuming the threads, see scenario b) below, > - GDB doesn't send more than one vCont s actions in one vCont > packet, although RSP doc doesn't say this. > > It is straightforward to insert reinsert breakpoints for vCont;s, > but I am not sure when to delete them. Here are some scenarios, > > a) vCont;s thread A, and vCont;c thread B. Thread A hits the reinsert > breakpoints, and GDBserver can remove them. What is the proper > place to remove them? > > b) vCont;s thread A, and vCont;c thread B. Thread B hits breakpoints > (not reinsert), do we remove reinsert breakpoints? My answer is > no. In the following step-over, reinsert breakpoints for step-over > are deleted, but reinsert breakpoints for vCont;s (thread A) are still > there. > > c) vCont;s thread A, and vCont;c thread B. Thread B hits the reinsert > breakpoints (for thread A vCont;s), do we remove reinsert breakpoints? > I think no, we can just step over it for thread B. > > d) vCont;s thread A, and vCont;c thread B. A signal arrives, do we remove > reinsert breakpoints? Yes, I think so. > > IMO, b) requires reinsert breakpoint thread specific, so that we can delete > reinsert breakpoints for step-over of thread B, but keep reinsert breakpoints > for vCont;s of thread A. That is what patch 1 does. > > I tried different ways to remove reinsert breakpoints in GDBserver, but still > can't fix fails in gdb.threads/schedlock.exp, that the program gets SIGILL or > SIGSEGV. These fails can't happen in every run, and they are disappeared > when I turn on debugging output in GDBserver. I suspect they are about the > improper management to reinsert breakpoints. > I'm not sure at the moment but this makes me think of an issue I sent here: https://www.sourceware.org/ml/gdb/2015-11/msg00030.html Actually thanks to a good discussion with LTTng maintainer, (Mathieu Desnoyer) last week I got the hint that this could be due to the situation described here: https://community.arm.com/groups/processors/blog/2010/02/17/caches-and-self-modifying-code Short story, the instruction cache could be out of sync after we've removed a software breakpoint and the processor would execute the breakpoint instruction causing a SIGILL rather then the original memory. The solution however, calling __clear_cache(...) requires that we're in the same process for the memory addresses to be valid, I think, so I'm not sure how to fix this yet... I'm still early in my investigation but it may be something to consider. > (gdb) PASS: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=1: next to increment (5) > next^M > 78 while (*myp > 0)^M > (gdb) next^M > ^M > Thread 1 "schedlock" received signal SIGILL, Illegal instruction.^M > [Switching to Thread 3797.3797]^M > 0x000087f8 in thread_function (arg=0x0) at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.threads/schedlock.c:78^M > 78 while (*myp > 0)^M > (gdb) FAIL: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=1: next to increment (6) > > Any ideas on the overall design, how to handle vCont;s in GDBserver using > software single step? or is it a completely wrong thing to handle vCont;s > using software single step? > > *** BLURB HERE *** > > Yao Qi (3): > make reinsert breakpoint thread specific > use reinsert breakpoint for vCont;s > [GDBserver] Support vCont s and S actions with software single step > > gdb/gdbserver/linux-low.c | 37 ++++++++++++++++++++++++++++++++----- > gdb/gdbserver/mem-break.c | 29 ++++++++++++++++++++++++++--- > gdb/gdbserver/mem-break.h | 13 +++++++++---- > gdb/gdbserver/server.c | 13 ++++++++----- > 4 files changed, 75 insertions(+), 17 deletions(-)