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 16:28:14 +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> <557ECCA5 dot 7050506 at redhat dot com> <83vbepngxm dot fsf at gnu dot org>
On 06/15/2015 04:13 PM, Eli Zaretskii wrote:
>> Date: Mon, 15 Jun 2015 14:01:25 +0100
>> From: Pedro Alves <palves@redhat.com>
>> CC: gdb@sourceware.org
>>
>>> if (!tp->control.in_infcall)
>>> set_running (user_visible_resume_ptid (user_step), 1);
>>>
>>> it winds up calling 'set_running', because the in_infcall flag is set
>>> on the thread that called the inferior function, not on the thread
>>> which was started and triggered TARGET_WAITKIND_SPURIOUS.
>>>
>>> So 'set_running' is called, and it is called with minus_one_ptid,
>>> which then has the effect of marking all the threads as running.
>>
>> So that should mean that even for GNU/Linux, it should be possible
>> to end in the exact same, when any thread other than the one that we
>> had started the infcall in reports an event that doesn't cause a stop.
>> E.g., a thread specific breakpoint, a "handle nostop" signal, etc.
>
> Does that involve minus_one_ptid on GNU/Linux as well? If not, that
> call will not mark all threads as running, will it?
It does. user_visible_resume_ptid returns the same irrespective
of target_can_async.
Thanks,
Pedro Alves