From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24009 invoked by alias); 28 Jun 2013 06:22:35 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 23997 invoked by uid 89); 28 Jun 2013 06:22:34 -0000 X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from ms9.webland.ch (HELO ms9smtp.webland.ch) (92.43.217.109) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 28 Jun 2013 06:22:32 +0000 Received: from ([77.57.22.1]) by ms9smtp.webland.ch (Webland Mail Server v. 10.4.1) with ASMTP id NMY85026 for ; Fri, 28 Jun 2013 08:22:26 +0200 Received: from localhost (localhost [127.0.0.1]) by macserver.private (Postfix) with ESMTP id ADC0B183D9DE; Fri, 28 Jun 2013 08:22:23 +0200 (CEST) Received: from macserver.private ([127.0.0.1]) by localhost (macserver.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sS49InnqSlFi; Fri, 28 Jun 2013 08:22:22 +0200 (CEST) Received: from [192.168.1.22] (unknown [192.168.1.22]) by macserver.private (Postfix) with ESMTP id AACC0183D9D2 for ; Fri, 28 Jun 2013 08:22:22 +0200 (CEST) Message-ID: <51CD2B96.6040607@indel.ch> Date: Fri, 28 Jun 2013 06:22:00 -0000 From: Raphael Zulliger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Why does "target remote" to a non-stop target stop one thread References: <51CCA2AB.1000008@embecosm.com> In-Reply-To: <51CCA2AB.1000008@embecosm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00066.txt.bz2 I can't answer your question, but I once asked a similar one, see http://sourceware.org/ml/gdb/2010-12/msg00048.html I still think that this is a GDB bug. I therefore use a patch like this: @@ -2669,8 +2669,11 @@ notice_new_inferior (ptid_t ptid, int leave_running, int from_tty) /* We're going to install breakpoints, and poke at memory, ensure that the inferior is stopped for a moment while we do that. */ - target_stop (inferior_ptid); - + /* But not if the target should be kept running - which + is the case for all Indel target during attach... */ + if( !leave_running ) { + target_stop (inferior_ptid); + } inferior->control.stop_soon = STOP_QUIETLY_REMOTE; /* Wait for stop before proceeding. */ On 06/27/2013 10:38 PM, Jeremy Bennett wrote: > I'm working on GDB for a remote target, using non-stop mode. > > When I connect to the target, even in non-stop mode, it insists on > stopping one thread. The comment in notice_new_inferior () is: > >> /* We're going to install breakpoints, and poke at memory, >> ensure that the inferior is stopped for a moment while we do >> that. */ > My question is, why we need to stop any thread. Surely the whole point > of non-stop mode is that we don't generally want to stop any threads if > it can be avoided. > > I'd appreciate understanding the thinking behind this, before I start > suggesting patches to change the behavior. > > Thanks, > > > Jeremy >