Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 1/7] Merge async and sync code paths some more
Date: Fri, 16 Oct 2015 17:05:00 -0000	[thread overview]
Message-ID: <20151016170515.GI3341@adacore.com> (raw)
In-Reply-To: <562127AB.4050303@redhat.com>

> I had forgotten how building on Cygwin takes ages! :-P

:-)

> So my main gripe with the patch is this:
> 
> @@ -2821,6 +2821,15 @@ attach_command (char *args, int from_tty)
>  	mark_infrun_async_event_handler ();
>        return;
>      }
> +  else
> +    {
> +      /* We don't expect any additional attach event from the target.
> +	 So make sure that the infrun_async_event_handler is disabled.
> +	 Otherwise, the main event loop might believe that we have
> +	 inferior events ready, causing us to wait for those event
> +	 that will never come, since our inferior is now stopped.  */
> +      infrun_async (0);
> +    }
> 
> If debugging more than one inferior (granted, Windows doesn't
> support this, but, alas), this prevents gdb from reacting to pending events
> for threads of the other inferior.

Ah, yes indeed. And besides, the patch is not Windows-specific
either, so presumably could negatively affect another target
that does support multi-inferior debugging.

> How about we make do_initial_windows_stuff call windows_wait/windows_resume
> directly, like we did for gdbserver here:
> 
>   https://sourceware.org/ml/gdb-patches/2013-12/msg00371.html
> 
> As mentioned in that thread, I've wanted to do this before
> in order to get rid of stop_after_trap.
> 
> The patch below seems to work for me.

Of course! Why take the roundabout way when you can take the direct
route? I don't see a reason in this case, and it completely avoids
the issue of the async even handler. And it looks like a nice
simplification to boot, at least to me.

Patch looks good, and I tested it against AdaCore's testsuite, showing
that it fixes the "attach" regressions without introducing any new
failure.

Slightly unrelated to your patch, now, but would you mind sharing
your thoughts on:

> I couldn't figure out why we needed both infrun_async and
> mark_infrun_async_event_handler, and in particular, I didn't
> see the need for the infrun_is_async != enable guard.
> So, this patch just makes infrun_async always call the
> relevant {mark,clear}_infrun_async_event_handler routine.
>
> If you agree that's the right thing to do, I propose we delete
> {mark,clear}_infrun_async_event_handler, or replace them by
> the associated infrun_async routine. Although, from someone
> not very familiar with all this async stuff, the function
> names {mark,clear}_infrun_async_event_handler speak a little
> more to me. On the other hand, I like infrun_async because of
> the debug trace. So we could also eliminate infrun_async and
> move the debug trace into {mark,clear}_infrun_async_event_handler.
> We'd have to make clear_infrun_async_event_handler non-static.

If there is an improvement to be had, be it just adding more comments,
I can take care of that.

Thanks a lot!
-- 
Joel


  reply	other threads:[~2015-10-16 17:05 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-12 17:02 [PATCH 0/7] Replace continuations with an extendable "class" Pedro Alves
2015-08-12 17:02 ` [PATCH 1/7] Merge async and sync code paths some more Pedro Alves
2015-08-12 19:48   ` Simon Marchi
2015-08-17 17:54     ` Pedro Alves
2015-08-17 19:28       ` Simon Marchi
2015-08-18 10:48   ` Yao Qi
2015-08-19 14:11     ` Pedro Alves
2015-08-27 13:26       ` Yao Qi
2015-10-16  0:35   ` Joel Brobecker
2015-10-16 12:24     ` Pedro Alves
2015-10-16 16:22       ` Joel Brobecker
2015-10-16 16:37         ` Pedro Alves
2015-10-16 17:05           ` Joel Brobecker [this message]
2015-10-22 16:18             ` Pedro Alves
2015-08-12 17:02 ` [PATCH 4/7] Convert the until/advance commands to thread_fsm mechanism Pedro Alves
2015-08-12 17:02 ` [PATCH 2/7] Replace "struct continuation" mechanism by something more extensible Pedro Alves
2015-08-18 12:50   ` Yao Qi
2015-08-19 14:55     ` Pedro Alves
2015-08-12 17:02 ` [PATCH 3/7] Convert infcalls to thread_fsm mechanism Pedro Alves
2015-08-12 17:11 ` [PATCH 6/7] Garbage collect thread continuations Pedro Alves
2015-08-12 17:11 ` [PATCH 5/7] Garbage collect dummy_frame_ctx_saver Pedro Alves
2015-08-12 17:11 ` [PATCH 7/7] Delete enum inferior_event_handler::INF_TIMER Pedro Alves
2015-08-18 11:22   ` Yao Qi
2015-08-18 12:52 ` [PATCH 0/7] Replace continuations with an extendable "class" Yao Qi
2015-08-19 14:56   ` Pedro Alves
2015-09-09 17:33   ` Pedro Alves

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=20151016170515.GI3341@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.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