From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27391 invoked by alias); 5 Apr 2016 17:43:22 -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 26145 invoked by uid 89); 5 Apr 2016 17:43:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=our, arranged X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 05 Apr 2016 17:43:17 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1anV0U-0006JL-Tr from Luis_Gustavo@mentor.com ; Tue, 05 Apr 2016 10:43:14 -0700 Received: from [134.86.127.233] (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.3.224.2; Tue, 5 Apr 2016 10:43:14 -0700 Subject: Re: why does GDB always stop a thread when connecting? References: <63F1AEE13FAE864586D589C671A6E18B043125@MX203CL03.corp.emc.com> To: "taylor, david" , "gdb@sourceware.org" Reply-To: Luis Machado From: Luis Machado Message-ID: <5703F931.3020705@codesourcery.com> Date: Tue, 05 Apr 2016 17:43:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <63F1AEE13FAE864586D589C671A6E18B043125@MX203CL03.corp.emc.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00000.txt.bz2 On 03/28/2016 04:12 PM, taylor, david wrote: > Why does GDB always stop a thread? > > We set non-stop before connecting to our remote target. > And during the initial back and forth, GDB always tells the > first thread returned by qfThreadInfo to stop. > > Because of this we have arranged for the first thread in the > list to be a thread that does nothing of consequence -- it is > imminently stoppable. > > But, I would like to understand *WHY* GDB is stopping the thread. > > While registers aren't available if the thread is not stopped, that is > to be expected. Memory can be read and written. Tracepoints and > breakpoints can be created, enabled, disabled, deleted... Trace > experiments can be run. Trace frames can be examined... > > Why does GDB need a stopped thread when it connects to the > target? > > Does setting "may-interrupt" to "off" help?