From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32759 invoked by alias); 28 Mar 2016 21:12: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 32750 invoked by uid 89); 28 Mar 2016 21:12:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=arranged, Hx-languages-length:788, connects, our X-HELO: mailuogwdur.emc.com Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 28 Mar 2016 21:12:24 +0000 Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u2SLCLAI013612 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Mar 2016 17:12:22 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u2SLCLAI013612 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com u2SLCLAI013612 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd52.lss.emc.com (RSA Interceptor) for ; Mon, 28 Mar 2016 17:12:02 -0400 Received: from MXHUB224.corp.emc.com (MXHUB224.corp.emc.com [10.253.68.94]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u2SLC6nZ017021 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Mon, 28 Mar 2016 17:12:06 -0400 Received: from MX203CL03.corp.emc.com ([fe80::4dee:b763:b476:8fbc]) by MXHUB224.corp.emc.com ([10.253.68.94]) with mapi id 14.03.0266.001; Mon, 28 Mar 2016 17:12:05 -0400 From: "taylor, david" To: "gdb@sourceware.org" Subject: why does GDB always stop a thread when connecting? Date: Mon, 28 Mar 2016 21:12:00 -0000 Message-ID: <63F1AEE13FAE864586D589C671A6E18B043125@MX203CL03.corp.emc.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public X-SW-Source: 2016-03/txt/msg00050.txt.bz2 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?