From: Andrew Burgess <aburgess@redhat.com>
To: "Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: Mihails Strasuns <mihails.strasuns@intel.com>,
"Schimpe, Christina" <christina.schimpe@intel.com>
Subject: RE: [PATCH 4/8] gdb, infrun: refactor part of `proceed` into separate function
Date: Tue, 04 Jul 2023 16:24:57 +0100 [thread overview]
Message-ID: <87cz17lmwm.fsf@redhat.com> (raw)
In-Reply-To: <DM4PR11MB73039262D5F4FC0B222F559CC424A@DM4PR11MB7303.namprd11.prod.outlook.com>
"Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com> writes:
> On Thursday, June 22, 2023 3:17 PM, Andrew Burgess wrote:
>> From: Mihails Strasuns <mihails.strasuns@intel.com>
>>
>> Split the thread resuming code from proceed into new function
>> proceed_resume_thread_checked.
>>
>> Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
>> ---
>> gdb/infrun.c | 148 +++++++++++++++++++++++++++------------------------
>> 1 file changed, 79 insertions(+), 69 deletions(-)
>>
>> diff --git a/gdb/infrun.c b/gdb/infrun.c
>> index 5b0257076f0..b10b7c59652 100644
>> --- a/gdb/infrun.c
>> +++ b/gdb/infrun.c
>> @@ -3268,6 +3268,82 @@ check_multi_target_resumption (process_stratum_target *resume_target)
>> }
>> }
>>
>> +/* Helper function for `proceed`. Check if thread TP is suitable for
>> + resuming, and, if it is, switch to the thread and call
>> + `keep_going_pass_signal`. If TP is not suitable for resuming then this
>> + function will just return without switching threads. */
>> +
>> +static void
>> +proceed_resume_thread_checked (thread_info *tp)
>> +{
>> + if (!tp->inf->has_execution ())
>> + {
>> + infrun_debug_printf ("[%s] target has no execution",
>> + tp->ptid.to_string ().c_str ());
>> + return;
>> + }
>> +
>> + if (tp->resumed ())
>> + {
>> + infrun_debug_printf ("[%s] resumed",
>> + tp->ptid.to_string ().c_str ());
>> + gdb_assert (tp->executing () || tp->has_pending_waitstatus ());
>> + return;
>> + }
>> +
>> + if (thread_is_in_step_over_chain (tp))
>> + {
>> + infrun_debug_printf ("[%s] needs step-over",
>> + tp->ptid.to_string ().c_str ());
>> + return;
>> + }
>> +
>> + /* When handling a vfork GDB removes all breakpoints from the program
>> + space in which the vfork is being handled, as such we must take care
>> + not to resume any thread other than the vfork parent -- resuming the
>> + vfork parent allows GDB to receive and handle the 'vfork done'
>> + event. */
>> + if (tp->inf->thread_waiting_for_vfork_done != nullptr)
>> + {
>> + if (target_is_non_stop_p ())
>> + {
>> + /* For non-stop targets, regardless of whether GDB is using
>> + all-stop or non-stop mode, threads are controlled
>> + individually.
>> +
>> + When a thread is handling a vfork, breakpoints are removed
>> + from the inferior (well, program space in fact), so it is
>> + critical that we don't try to resume any thread other than the
>> + vfork parent. */
>> + if (tp != tp->inf->thread_waiting_for_vfork_done)
>> + {
>> + infrun_debug_printf ("[%s] thread %s of this inferior is "
>> + "waiting for vfork-done",
>> + tp->ptid.to_string ().c_str (),
>> + tp->inf->thread_waiting_for_vfork_done
>> + ->ptid.to_string ().c_str ());
>> + return;
>> + }
>> + }
>> + else
>> + {
>> + /* For all-stop targets, when we attempt to resume the inferior,
>> + we will in fact only resume the vfork parent thread, this is
>> + handled in internal_resume_ptid, as such, there is nothing
>> + more that needs doing here. */
>
> I wonder if here we should do
>
> gdb_assert (tp == tp->inf->thread_waiting_for_vfork_done);
>
That's a good idea. I've also updated the comment within this else
block as the current text doesn't really cover why this assert holds.
I've posted a V2 with this change.
Thanks,
Andrew
> -Baris
>
>> + }
>> + }
>> +
>> + infrun_debug_printf ("resuming %s",
>> + tp->ptid.to_string ().c_str ());
>> +
>> + execution_control_state ecs (tp);
>> + switch_to_thread (tp);
>> + keep_going_pass_signal (&ecs);
>> + if (!ecs.wait_some_more)
>> + error (_("Command aborted."));
>> +}
>> +
>> /* Basic routine for continuing the program in various fashions.
>>
>> ADDR is the address to resume at, or -1 for resume where stopped.
>> @@ -3456,77 +3532,11 @@ proceed (CORE_ADDR addr, enum gdb_signal siggnal)
>> resume_ptid))
>> {
>> switch_to_thread_no_regs (tp);
>> -
>> - if (!tp->inf->has_execution ())
>> - {
>> - infrun_debug_printf ("[%s] target has no execution",
>> - tp->ptid.to_string ().c_str ());
>> - continue;
>> - }
>> -
>> - if (tp->resumed ())
>> - {
>> - infrun_debug_printf ("[%s] resumed",
>> - tp->ptid.to_string ().c_str ());
>> - gdb_assert (tp->executing () || tp->has_pending_waitstatus ());
>> - continue;
>> - }
>> -
>> - if (thread_is_in_step_over_chain (tp))
>> - {
>> - infrun_debug_printf ("[%s] needs step-over",
>> - tp->ptid.to_string ().c_str ());
>> - continue;
>> - }
>> -
>> - /* If a thread of that inferior is waiting for a vfork-done
>> - (for a detached vfork child to exec or exit), breakpoints are
>> - removed. We must not resume any thread of that inferior, other
>> - than the one waiting for the vfork-done. */
>> - if (tp->inf->thread_waiting_for_vfork_done != nullptr
>> - && tp != tp->inf->thread_waiting_for_vfork_done)
>> - {
>> - infrun_debug_printf ("[%s] another thread of this inferior is "
>> - "waiting for vfork-done",
>> - tp->ptid.to_string ().c_str ());
>> - continue;
>> - }
>> -
>> - infrun_debug_printf ("resuming %s",
>> - tp->ptid.to_string ().c_str ());
>> -
>> - execution_control_state ecs (tp);
>> - switch_to_thread (tp);
>> - keep_going_pass_signal (&ecs);
>> - if (!ecs.wait_some_more)
>> - error (_("Command aborted."));
>> - }
>> - }
>> - else if (!cur_thr->resumed ()
>> - && !thread_is_in_step_over_chain (cur_thr))
>> - {
>> - /* In non-stop mode, if a there exists a thread waiting for a vfork
>> - then only allow that thread to resume (breakpoints are removed
>> - from an inferior when handling a vfork).
>> -
>> - We check target_is_non_stop_p here rather than just checking the
>> - non-stop flag, though these are equivalent (all-stop on a
>> - non-stop target was handled in a previous block, so at this
>> - point, if target_is_non_stop_p then GDB must be running on
>> - non-stop mode). By using target_is_non_stop_p it will be easier
>> - to merge this block with the previous in a later commit. */
>> - if (!(target_is_non_stop_p ()
>> - && cur_thr->inf->thread_waiting_for_vfork_done != nullptr
>> - && cur_thr->inf->thread_waiting_for_vfork_done != cur_thr))
>> - {
>> - /* The thread wasn't started, and isn't queued, run it now. */
>> - execution_control_state ecs (cur_thr);
>> - switch_to_thread (cur_thr);
>> - keep_going_pass_signal (&ecs);
>> - if (!ecs.wait_some_more)
>> - error (_("Command aborted."));
>> + proceed_resume_thread_checked (tp);
>> }
>> }
>> + else
>> + proceed_resume_thread_checked (cur_thr);
>>
>> disable_commit_resumed.reset_and_commit ();
>> }
>> --
>> 2.25.4
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
next prev parent reply other threads:[~2023-07-04 15:25 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-22 13:17 [PATCH 0/8] Some vfork related fixes Andrew Burgess
2023-06-22 13:17 ` [PATCH 1/8] gdb: catch more errors in gdb.base/foll-vfork.exp Andrew Burgess
2023-06-22 13:17 ` [PATCH 2/8] gdb: don't restart vfork parent while waiting for child to finish Andrew Burgess
2023-06-22 13:17 ` [PATCH 3/8] gdb: fix an issue with vfork in non-stop mode Andrew Burgess
2023-06-22 13:17 ` [PATCH 4/8] gdb, infrun: refactor part of `proceed` into separate function Andrew Burgess
2023-06-28 8:47 ` Aktemur, Tankut Baris
2023-07-04 15:24 ` Andrew Burgess [this message]
2023-06-22 13:17 ` [PATCH 5/8] gdb: don't resume vfork parent while child is still running Andrew Burgess
2023-06-22 13:17 ` [PATCH 6/8] gdb/testsuite: expand gdb.base/foll-vfork.exp Andrew Burgess
2023-06-22 13:17 ` [PATCH 7/8] gdb/testsuite: remove use of sleep from gdb.base/foll-vfork.exp Andrew Burgess
2023-06-22 13:17 ` [PATCH 8/8] gdb: additional debug output in infrun.c and linux-nat.c Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 0/8] Some vfork related fixes Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 1/8] gdb: catch more errors in gdb.base/foll-vfork.exp Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 2/8] gdb: don't restart vfork parent while waiting for child to finish Andrew Burgess
2023-07-05 10:08 ` Aktemur, Tankut Baris
2023-07-04 15:22 ` [PATCHv2 3/8] gdb: fix an issue with vfork in non-stop mode Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 4/8] gdb, infrun: refactor part of `proceed` into separate function Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 5/8] gdb: don't resume vfork parent while child is still running Andrew Burgess
2023-07-18 20:42 ` Simon Marchi
2023-07-21 9:47 ` Andrew Burgess
2023-07-23 8:53 ` Andrew Burgess
2023-08-16 14:02 ` Andrew Burgess
2023-08-17 6:36 ` Tom de Vries
2023-08-17 7:01 ` Tom de Vries
2023-08-17 8:06 ` Tom de Vries
2023-08-17 8:22 ` Tom de Vries
2023-07-04 15:22 ` [PATCHv2 6/8] gdb/testsuite: expand gdb.base/foll-vfork.exp Andrew Burgess
2023-07-05 11:22 ` Aktemur, Tankut Baris
2023-07-04 15:22 ` [PATCHv2 7/8] gdb/testsuite: remove use of sleep from gdb.base/foll-vfork.exp Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 8/8] gdb: additional debug output in infrun.c and linux-nat.c Andrew Burgess
2023-07-05 11:30 ` [PATCHv2 0/8] Some vfork related fixes Aktemur, Tankut Baris
2023-07-17 8:53 ` Andrew Burgess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cz17lmwm.fsf@redhat.com \
--to=aburgess@redhat.com \
--cc=christina.schimpe@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=mihails.strasuns@intel.com \
--cc=tankut.baris.aktemur@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).