This is the mail archive of the 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

>>>>> "Pedro" == Pedro Alves <> 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
async.  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.

This is different from software single-step because, IIUC, SSS is an
intrinsic feature of some ports; whereas sync targets are purely
internal issues to 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".


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