From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112760 invoked by alias); 15 Jun 2015 15:27:28 -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 112744 invoked by uid 89); 15 Jun 2015 15:27:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout22.012.net.il Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 Jun 2015 15:27:26 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NPZ00H00S7LIP00@a-mtaout22.012.net.il> for gdb@sourceware.org; Mon, 15 Jun 2015 18:27:14 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NPZ00HF4S9EHX10@a-mtaout22.012.net.il>; Mon, 15 Jun 2015 18:27:14 +0300 (IDT) Date: Mon, 15 Jun 2015 15:27:00 -0000 From: Eli Zaretskii Subject: Re: Inadvertently run inferior threads In-reply-to: <557ED083.1060804@redhat.com> To: Pedro Alves Cc: gdb@sourceware.org Reply-to: Eli Zaretskii Message-id: <83si9tngaj.fsf@gnu.org> 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> <557ED083.1060804@redhat.com> X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00029.txt.bz2 > Date: Mon, 15 Jun 2015 14:17:55 +0100 > From: Pedro Alves > CC: gdb@sourceware.org > > 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: I guess this happens unless the breakpoint was thread-specific, right? Otherwise the async execution would be much less useful, I presume. But I digress. > > 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. I'm not sure I follow. From this user's (admittedly semi-naive) POV, what happens with such a breakpoint is this: . Inferior hits the breakpoint and stops; the thread is now "not running". . GDB gets control and evaluates the condition. . When GDB issues the infcall, as part of evaluating the condition, the thread resumes -- now it is "running". . The thread that runs the infcall reaches the end of the function and stops at the temporary breakpoint GDB inserted there -- the thread is again "not running". . GDB evaluates the return value, decides that the condition was not fulfilled, and resumes the inferior -- the thread is now "running" again. Or GDB decides that the condition _was_ fulfilled, in which case the thread stays at its "not running" state. So it sounds to me that if we faithfully reflect the actual running state of the thread during this scenario, without any exceptions or exemptions, we are good. You say "internal run control machinery details", but since these controls actually run and stop user threads, I don't see why we should work so hard to conceal them, and in the process shoot ourselves in the foot. What am I missing? Thanks for taking the time to explain these details.