From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107592 invoked by alias); 6 May 2016 10:32:33 -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 107552 invoked by uid 89); 6 May 2016 10:32:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=management, HERE X-HELO: mail-pa0-f53.google.com Received: from mail-pa0-f53.google.com (HELO mail-pa0-f53.google.com) (209.85.220.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 06 May 2016 10:32:30 +0000 Received: by mail-pa0-f53.google.com with SMTP id xk12so46694169pac.0 for ; Fri, 06 May 2016 03:32:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id; bh=lhlgIgQIW2wX3kerA6nyx8BbFaJh0Uh9odAS1Lc6iAI=; b=a5w/ISOez/fwfGFJWkITjzG8Wq3H6ifMM9IUeXy1C+0fw9JvBTliAib4rBt0I/BfMT 3WVm07MpqlbWHTtIXRDFxHmTJf+WjUCf0KHWP9oeZdDqI+em47X+buvY9yovmduqWgvd WgHmu1qRoB4cU1NstW4yGKKBoShNBkzqGNNPhf6krSsvlteLrSi4maY9f/Dr2HMOjacH 8DzfjzuPR1CyEFyJWMyKZP3EgKg+/wOqqT6LBNu/VU4BZ3SP6lUMGNDuphIQ44IaJ7Rh o7OjZzu6mZkngdAJrCjOvctJDF4PC45lIB2Kj+W/cDq0TNoJSaY53B++vOe2DEOeXLT+ NaBQ== X-Gm-Message-State: AOPr4FXSusiQC4R6yMVQmq3/UMvUd4pOTJJV1ZtZlINUZRyBgw+yrezhPMFB6C5ntbWM0Q== X-Received: by 10.66.218.161 with SMTP id ph1mr27194952pac.83.1462530748742; Fri, 06 May 2016 03:32:28 -0700 (PDT) Received: from E107787-LIN.cambridge.arm.com (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id qm10sm20041121pac.33.2016.05.06.03.32.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 06 May 2016 03:32:28 -0700 (PDT) From: Yao Qi X-Google-Original-From: Yao Qi To: gdb-patches@sourceware.org Subject: [RFC 0/3] Use reinsert breakpoint for vCont;s Date: Fri, 06 May 2016 10:32:00 -0000 Message-Id: <1462530736-25117-1-git-send-email-yao.qi@linaro.org> X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00086.txt.bz2 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. (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(-) -- 1.9.1