From: Pedro Alves <palves@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v4 2/9] add "this" pointers to more target APIs
Date: Fri, 08 Nov 2013 18:04:00 -0000 [thread overview]
Message-ID: <527D2323.2010708@redhat.com> (raw)
In-Reply-To: <87mwltcp8v.fsf@fleche.redhat.com>
On 10/28/2013 04:52 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
>
> Pedro> On 10/28/2013 04:37 PM, Tom Tromey wrote:
>>>
>>> It is all moot, I think. There is no reason for linux-nat to ever call
>>> linux_nat_is_async_p any more. I think we can drop all the dead code
>>> instead. I noted this in the first submission and said I will do it in
>>> a followup; but I think I'll just tack it on to this series instead.
>
> Pedro> I'd rather keep the code to allow forcing sync mode for a while,
> Pedro> to make it easier to debug problems and compare modes.
>
> With this series, there's no way to force sync mode.
That'll really make our lives complicated. We'll definitely
hit async specific problems, and not being able to easily
compare how sync behaves will be a nuisance. Also, given most
targets don't support async, I think it'll be very valuable
to easily check how sync mode works on native GNU/Linux as proxy
for those targets -- consider patches changing run control and
execution commands code. Heck, I've gone through the trouble
of implementing software single-step on x86 just to be able
to use that as proxy for sss targets. :-)
> I think maybe it could be done by adding a new "maint" setting.
Yeah, "set target-async" used to be a set of maint commands.
https://sourceware.org/ml/gdb-patches/2008-08/msg00423.html
We've come full circle. :-)
>
> We can't reuse "set target-async" due to the MI misuse, unless we're
> willing to change the default setting of this parameter based on the
> current interpreter. In fact an earlier version of my patch series did
> just this, but IIRC I thought it was too hackish.
Yeah, making the setting be MI specific is better.
> While we're here, I wonder now whether the distinction between "can
> async" and "is async" makes sense any more. I'm inclined to remove one
> of them.
Yeah, probably doesn't. We used to have this target_async_mask
mechanism, that got replaced by TARGET_WNOHANG:
https://sourceware.org/ml/gdb-patches/2009-05/msg00459.html
and forced waits:
https://sourceware.org/ml/gdb-patches/2011-06/msg00086.html
Before that, the target could support async, but have it
masked (so "can" would be true, "is" would be "false").
--
Pedro Alves
next prev parent reply other threads:[~2013-11-08 17:57 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-22 17:59 [PATCH v4 0/9] enable target-async by default Tom Tromey
2013-10-22 17:59 ` [PATCH v4 2/9] add "this" pointers to more target APIs Tom Tromey
2013-10-28 16:04 ` Pedro Alves
2013-10-28 16:37 ` Tom Tromey
2013-10-28 16:44 ` Pedro Alves
2013-10-28 16:52 ` Tom Tromey
2013-11-08 18:04 ` Pedro Alves [this message]
2013-11-08 21:53 ` Tom Tromey
2013-11-09 3:35 ` Pedro Alves
2013-12-06 17:40 ` Tom Tromey
2013-12-06 18:35 ` Pedro Alves
2013-12-06 18:23 ` Tom Tromey
2013-12-06 19:06 ` Pedro Alves
2013-10-22 17:59 ` [PATCH v4 3/9] add target method delegation Tom Tromey
2013-10-28 16:05 ` Pedro Alves
2013-10-28 17:51 ` Tom Tromey
2013-10-28 17:53 ` Tom Tromey
2013-10-29 20:55 ` Tom Tromey
2013-11-08 17:44 ` Pedro Alves
2013-12-11 22:03 ` Tom Tromey
2013-12-12 2:46 ` Tom Tromey
2013-12-13 22:07 ` Tom Tromey
2013-12-16 13:07 ` Pedro Alves
2013-12-16 21:21 ` Tom Tromey
2013-12-17 16:17 ` Pedro Alves
2013-12-18 18:29 ` Tom Tromey
2013-12-18 22:06 ` Tom Tromey
2013-12-19 16:03 ` Pedro Alves
2013-12-19 16:15 ` Tom Tromey
2013-12-20 19:24 ` Tom Tromey
2013-11-08 16:34 ` Pedro Alves
2013-10-22 17:59 ` [PATCH v4 4/9] PR gdb/13860: make -interpreter-exec console "list" behave more like "list" Tom Tromey
2013-10-22 17:59 ` [PATCH v4 1/9] fix latent bugs in ui-out.c Tom Tromey
2013-10-28 15:20 ` Pedro Alves
2013-10-28 17:36 ` Tom Tromey
2013-10-22 17:59 ` [PATCH v4 5/9] PR gdb/13860: make "-exec-foo"'s MI output equal to "foo"'s MI output Tom Tromey
2013-10-22 18:11 ` [PATCH v4 8/9] fix py-finish-breakpoint.exp with always-async Tom Tromey
2013-11-11 19:51 ` Pedro Alves
2013-12-09 17:53 ` Tom Tromey
2013-10-22 18:26 ` [PATCH v4 6/9] PR gdb/13860: don't lose '-interpreter-exec console EXECUTION_COMMAND''s output in async mode Tom Tromey
2013-10-22 18:26 ` [PATCH v4 9/9] enable target-async Tom Tromey
2013-10-22 20:15 ` Eli Zaretskii
2013-11-11 19:54 ` Pedro Alves
2013-11-12 20:53 ` Pedro Alves
2013-11-15 0:45 ` Tom Tromey
2013-11-18 15:42 ` Pedro Alves
2013-12-06 20:44 ` Tom Tromey
2013-12-09 12:01 ` Pedro Alves
2013-12-09 15:57 ` Tom Tromey
2014-02-21 20:23 ` Tom Tromey
2014-02-24 17:38 ` Tom Tromey
2013-10-22 19:00 ` [PATCH v4 7/9] make dprintf.exp pass in always-async mode Tom Tromey
2013-11-12 0:05 ` 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=527D2323.2010708@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@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