From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35820 invoked by alias); 15 Jun 2015 13:18:00 -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 35804 invoked by uid 89); 15 Jun 2015 13:17:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 15 Jun 2015 13:17:59 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id D44FEB1F90; Mon, 15 Jun 2015 13:17:57 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5FDHu2k031763; Mon, 15 Jun 2015 09:17:57 -0400 Message-ID: <557ED083.1060804@redhat.com> Date: Mon, 15 Jun 2015 13:18:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Eli Zaretskii CC: gdb@sourceware.org Subject: Re: Inadvertently run inferior threads References: <83h9tq3zu3.fsf@gnu.org> <55043A63.6020103@redhat.com> <8361a339xd.fsf@gnu.org> <5504555C.804@redhat.com> <550458E0.10206@redhat.com> <83y4jrsgui.fsf@gnu.org> <83ioaus6pt.fsf@gnu.org> In-Reply-To: <83ioaus6pt.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg00026.txt.bz2 On 06/11/2015 02:41 PM, Eli Zaretskii wrote: > And I have a question about your description of what happens on > GNU/Linux. You say: > >> #4 - result: _new_ threads end up in "running" state, even though they >> are stopped. > > My question is this: who or what stops the new threads that were > started by the function we infcall'ed? I know who stops them on > MS-Windows: the OS. GDB does, from within the target's target_wait implementation. For Linux, it's in linux-nat.c:linux_nat_wait_1: ... /* Now stop all other LWP's ... */ iterate_over_lwps (minus_one_ptid, stop_callback, NULL); /* ... and wait until all of them have reported back that they're no longer running. */ iterate_over_lwps (minus_one_ptid, stop_wait_callback, NULL); ... > Does the same happen on GNU/Linux (and other systems that support > asynchronous execution)? Yes. It's gdb's own code that does it, but from infrun.c's perspective, it's the same. > If so, I don't understand why we suppress > the stopped <-> running transitions when in infcall. Or at least the > running -> stopped transition. The comment in normal_stop tries to > explain this: Say you have a breakpoint with a condition that does an infcall, like: int return_false (void) { return 0 }; (gdb) b somewhere_in_a_loop if return_false() (gdb) c >From the perspective of the user, the thread is always running after that "c". The breakpoint stops for both "somewhere_in_a_loop" and for the infcall's dummy breakpoint are all internal run control machinery details. (BBL to reply to the rest.) Thanks, Pedro Alves