public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Natalia Saiapova <natalia.saiapova@intel.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v2 3/6] gdb/infcall: in condition evaluation register target back after infcall.
Date: Tue, 2 Mar 2021 11:26:06 +0000	[thread overview]
Message-ID: <20210302112606.GQ265215@embecosm.com> (raw)
In-Reply-To: <20201009112719.629-4-natalia.saiapova@intel.com>

* Natalia Saiapova via Gdb-patches <gdb-patches@sourceware.org> [2020-10-09 13:27:15 +0200]:

> After an inferior call is finished, the target is unregistered from
> the event loop.  However, if the inferior call has happened during
> the condition evaluation, we still want to get `stop` events from
> other threads in `wait_one`.  So, register the target back.

My first question after reading this patch and the commit message is,
why don't we stop the unregistering for the case when we shouldn't
unregister.

There's probably a really good answer, and you probably have all the
knowledge in your head.... but the commit message is a little terse.

Could you explain why it's better to let GDB do the wrong thing and
then patch it up, instead of just doing to right thing all along?

Also, it feels like this change should have a test.

Thanks,
Andrew





> 
> gdb/ChangeLog:
> 2020-08-26  Natalia Saiapova  <natalia.saiapova@intel.com>
> 	    Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
> 
> 	* infcall.c (run_inferior_call): In condition evaluation,
> 	register the target back after the infcall.
> 
> Co-authored-by: Natalia Saiapova <natalia.saiapova@intel.com>
> Co-authored-by: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
> 
> Signed-off-by: Natalia Saiapova <natalia.saiapova@intel.com>
> ---
>  gdb/infcall.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/gdb/infcall.c b/gdb/infcall.c
> index 399b1724ea2..0b0226f8e82 100644
> --- a/gdb/infcall.c
> +++ b/gdb/infcall.c
> @@ -667,6 +667,9 @@ run_inferior_call (struct call_thread_fsm *sm,
>  
>    call_thread->control.in_infcall = saved_in_infcall;
>  
> +  if (call_thread->control.in_cond_eval && target_can_async_p ())
> +    target_async (true);
> +
>    return caught_error;
>  }
>  
> -- 
> 2.17.1
> 
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Gary Kershaw
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
> 

  parent reply	other threads:[~2021-03-02 11:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200831123519.16232-1-natalia.saiapova () intel ! com>
2020-10-09 11:27 ` [PATCH v2 0/6] Fix inferior calls from breakpoint condition Natalia Saiapova
2020-10-09 11:27   ` [PATCH v2 1/6] gdb: add in_cond_eval field to thread_control_state struct Natalia Saiapova
2021-03-02 10:43     ` Andrew Burgess
2020-10-09 11:27   ` [PATCH v2 2/6] gdb/infrun: in condition evaluation resume only current thread Natalia Saiapova
2021-03-02 11:15     ` Andrew Burgess
2020-10-09 11:27   ` [PATCH v2 3/6] gdb/infcall: in condition evaluation register target back after infcall Natalia Saiapova
2020-10-19  0:53     ` Kevin Buettner
2021-03-02 11:26     ` Andrew Burgess [this message]
2020-10-09 11:27   ` [PATCH v2 4/6] gdb/infrun: in condition evaluation wait only for the current inferior Natalia Saiapova
2020-10-19  1:44     ` Kevin Buettner
2020-10-26 12:11       ` Saiapova, Natalia
2021-03-02 12:17         ` Andrew Burgess
2020-10-09 11:27   ` [PATCH v2 5/6] gdb/infrun: in condition evaluation do not stop all threads Natalia Saiapova
2020-10-09 11:27   ` [PATCH v2 6/6] gdb/testsuite: add tests for inferior calls in breakpoint conditions Natalia Saiapova
2020-10-12  0:49   ` [PATCH v2 0/6] Fix inferior calls from breakpoint condition Kevin Buettner

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=20210302112606.GQ265215@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=natalia.saiapova@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).