From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60484 invoked by alias); 21 Nov 2016 12:08:42 -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 60463 invoked by uid 89); 21 Nov 2016 12:08:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=antoine, Antoine, single-step, singlestep X-HELO: mail-wj0-f174.google.com Received: from mail-wj0-f174.google.com (HELO mail-wj0-f174.google.com) (209.85.210.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 21 Nov 2016 12:08:40 +0000 Received: by mail-wj0-f174.google.com with SMTP id mp19so25834484wjc.1 for ; Mon, 21 Nov 2016 04:08:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=O76jjjb3ayB8ZLQpOQ9tLV7fXruR+d7eBxbtxJo+URI=; b=a2Yjn+aqyLRltNZ++/YLSo6cR3emlvFqjPTIjmbFjHeddoIckz/wbbD1Y/TcrIMFiR ugqDRnEwrRXJT6CGKWkqhMgS4uiyVqp20icDpaAUJPJVMpUVAkukrluhcE+3+cGtomt6 Pv6PVb6obrbgj7NUIrKNalMvqxxrkjJyiHINyaLMm8I7p9CBsx0CDkHTZe+lPNyGJfbL GOH6pc0S8u2MHXRSSCUMb1d2PN8nCiwts74PNrBtqIIT4/6dWh7WT7EOvVcbok6DHavB bVOsyb/HSdV4ajRJq9dTLpyPtvqisxqzEAaDoz5rpX+Y4qmWhw6lJj05BsKWkqdk08af AtKQ== X-Gm-Message-State: AKaTC02gbc7zA8naqNcxd4SGnZ6Zo6ekBAxrI4bKDRdxmluuuhwok8jIFE4N20iGIirzEg== X-Received: by 10.195.30.43 with SMTP id kb11mr8908692wjd.131.1479730118099; Mon, 21 Nov 2016 04:08:38 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id r138sm19217652wme.9.2016.11.21.04.08.35 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 21 Nov 2016 04:08:37 -0800 (PST) Date: Mon, 21 Nov 2016 12:08:00 -0000 From: Yao Qi To: Antoine Tremblay Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH 0/9 V3] Use reinsert breakpoint for vCont;s Message-ID: <20161121120822.GA28605@E107787-LIN> References: <1467295765-3457-1-git-send-email-yao.qi@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00600.txt.bz2 On Mon, Nov 14, 2016 at 02:10:32PM -0500, Antoine Tremblay wrote: > > > I do something slightly differently in V3. In my > > "V2 Use reinsert breakpoint for vCont;s", I install reinsert breakpoints > > for needed lwps in two places, linux_resume and proceed_all_lwps, which > > isn't ideal. > > > > After the chat with Pedro, we don't need to stop all threads when inserting > > reinsert breakpoint, so we can move the breakpoint installation further > > down to linux_resume_one_thread and proceed_one_lwp. > > I'm following up on random SIGILL/SIGSEGV when using software single stepping/ > range stepping with GDBServer on ARM. > > And I can't see why we don't need to stop all threads when inserting > reinsert breakpoint. > > Since linux_resume will call: > > find_inferior (&all_threads, linux_resume_one_thread, > &leave_all_stopped); > > This will start one thread after the other. So for example if thread 3 > has a single step breakpoint to install this will start thread 1, then > thread 2 and just modify the program's memory to install reinsert > breakpoints on thread 3 with thread 1 and 2 running. > > Thus leading to thread 1 or 2 executing invalid memory, thus the SIGILL > random problems... Single-step breakpoint is thread specific, so we don't need to stop other threads when inserting one for a specific thread. Given the example above, we insert single-step breakpoint for thread 3 on address A, if thread 1 goes through address A, but doesn't hit the breakpoint, IOW, thread 1 still sees the original instruction, that is nothing wrong, right? We don't expect thread 1 hits that breakpoint for thread 3 anyway. If thread 1 hits the breakpoint (IOW, thread 1 sees the breakpoint instruction), GDBserver just handles that SIGTRAP, and it has already know that there is a breakpoint on address A. Thread 1 either sees the original instruction on address A or the breakpoint instruction. Unless ptrace read/write 32-bit is not atomic, IOW, partial ptrace write result is visible to other threads, I don't see why we get SIGILL here. Note that we stop all threads when we remove single-step breakpoints because we want no thread sees single-step breakpoint in memory from their point of view afterwards. -- Yao (齐尧)