This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH v4 2/9] add "this" pointers to more target APIs
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 08 Nov 2013 21:53:28 +0000
- Subject: Re: [PATCH v4 2/9] add "this" pointers to more target APIs
- Authentication-results: sourceware.org; auth=none
- References: <1382464769-2465-1-git-send-email-tromey at redhat dot com> <1382464769-2465-3-git-send-email-tromey at redhat dot com> <526E8AF2 dot 7050202 at redhat dot com> <87r4b5cpxd dot fsf at fleche dot redhat dot com> <526E9451 dot 6050103 at redhat dot com> <87mwltcp8v dot fsf at fleche dot redhat dot com> <527D2323 dot 2010708 at redhat dot com> <87ob5uodry dot fsf at fleche dot redhat dot com>
On 11/08/2013 08:10 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <email@example.com> writes:
> Tom> With this series, there's no way to force sync mode.
> Pedro> That'll really make our lives complicated. We'll definitely
> Pedro> hit async specific problems, and not being able to easily
> Pedro> compare how sync behaves will be a nuisance. Also, given most
> Pedro> targets don't support async, I think it'll be very valuable
> Pedro> to easily check how sync mode works on native GNU/Linux as proxy
> Pedro> for those targets -- consider patches changing run control and
> Pedro> execution commands code. Heck, I've gone through the trouble
> Pedro> of implementing software single-step on x86 just to be able
> Pedro> to use that as proxy for sss targets. :-)
> Ok. I will add it back under "maint".
> I think the in the long run it would be better if all targets were
Yes, of course. It requires per-target work, however... I'm not
seeing that happen anytime soon. (and djgpp might be a challenge.)
> I think this is preferable because async is an enabling feature
> for other features, and because removing sync mode would simplify one of
> the more complicated parts of gdb.
>>> While we're here, I wonder now whether the distinction between "can
>>> async" and "is async" makes sense any more.
> Pedro> Yeah, probably doesn't.
> I'll remove "is_async". Unless you'd rather I remove "can_async".
No, that's fine. "is_async" would be my choice as well.