From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116054 invoked by alias); 5 Apr 2016 20:52:19 -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 115941 invoked by uid 89); 5 Apr 2016 20:52:18 -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=H*UA:1.5, Machado, machado, Luis X-HELO: mailuogwhop.emc.com Received: from mailuogwhop.emc.com (HELO mailuogwhop.emc.com) (168.159.213.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 05 Apr 2016 20:52:08 +0000 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u35Kq46A030273 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Apr 2016 16:52:04 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com u35Kq46A030273 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com u35Kq46A030273 Received: from mailsyshubprd51.lss.emc.com (mailsyshubprd51.lss.emc.com [10.106.48.26]) by maildlpprd03.lss.emc.com (RSA Interceptor); Tue, 5 Apr 2016 16:50:18 -0400 Received: from usendtaylorx2l (d5170089.lss.emc.com [10.243.146.89]) by mailsyshubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u35Kpik2002839; Tue, 5 Apr 2016 16:51:45 -0400 Received: by usendtaylorx2l (Postfix, from userid 26043) id 79299264FD2; Tue, 5 Apr 2016 16:51:44 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l (Postfix) with ESMTP id 595A8264140; Tue, 5 Apr 2016 16:51:44 -0400 (EDT) From: David Taylor To: Luis Machado cc: gdb@sourceware.org, dtaylor@emc.com Subject: Re: why does GDB always stop a thread when connecting? Date: Tue, 05 Apr 2016 20:52:00 -0000 Message-ID: <8684.1459889504@usendtaylorx2l> X-RSA-Classifications: public X-Sentrion-Hostname: mailuogwprd03.lss.emc.com X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00001.txt.bz2 On 04/05/2016 01:43 PM, Luis Machado wrote: Does setting "may-interrupt" to "off" help? I'll try that as a possible kludgey workaround. But, if it works, since the user should be able to stop and interrupt threads -- we just don't want GDB doing so when not asked to do so -- it would mean the user or the GUI would have to do something like: set may-interrupt off issue target command... set may-interrupt on For our target, and I suspect for many of the non-stop remote targets out there, the only GDB operations that come to mind that require a stopped thread are to read and/or write the registers of the thread and to single step the thread. We do not require a stopped thread to create or delete breakpoints. To enable of disable breakpoints. To create, delete, enable, or disable tracepoints. To start or stop a trace experiment. To read or write memory. IF there is no good reason for the current behavior, then I'm willing to write and test a patch. If there is a good reason, then perhaps a new user settable variable is needed to decide whether to do the pointless and gratuitous (to me) stop of a thread when connecting. David