This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Inadvertently run inferior threads
- From: Pedro Alves <palves at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb at sourceware dot org
- Date: Mon, 15 Jun 2015 14:17:55 +0100
- Subject: Re: Inadvertently run inferior threads
- Authentication-results: sourceware.org; auth=none
- References: <83h9tq3zu3 dot fsf at gnu dot org> <55043A63 dot 6020103 at redhat dot com> <8361a339xd dot fsf at gnu dot org> <5504555C dot 804 at redhat dot com> <550458E0 dot 10206 at redhat dot com> <83y4jrsgui dot fsf at gnu dot org> <83ioaus6pt dot fsf at gnu dot 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:
...
/* 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