This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v4 2/9] add "this" pointers to more target APIs


On 11/08/2013 08:10 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.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".

Thanks.

> 
> I think the in the long run it would be better if all targets were
> async.  

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.

Certainly.

>>> 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.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]