This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v4 3/9] add target method delegation
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 11 Dec 2013 15:02:52 -0700
- Subject: Re: [PATCH v4 3/9] add target method delegation
- Authentication-results: sourceware.org; auth=none
- References: <1382464769-2465-1-git-send-email-tromey at redhat dot com> <1382464769-2465-4-git-send-email-tromey at redhat dot com> <526E8B54 dot 8040104 at redhat dot com> <87eh75cmig dot fsf at fleche dot redhat dot com> <87a9htcme3 dot fsf at fleche dot redhat dot com> <87habz7q6g dot fsf at fleche dot redhat dot com> <527D1A84 dot 9040106 at redhat dot com>
>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
Pedro> So to take that example, if we made dummy_target.to_wait be the
Pedro> current to_wait default, which is to call noprocess(), then
Pedro> it'd be clear that target_delegate_wait shouldn't ever go past
Pedro> the loop, and then it'd be clear that an assertion is appropriate.
Pedro> target_wait would then be:
[...]
Pedro> WDYT?
It seems good to me.
I'll make a patch to normalize the delegation across all the target
methods. Too bad for me I already touched all these methods on the
multi-target branch -- ouch.
Testing revealed that we can't put the assert into
target_delegate_async. This is a funny one. The dummy target has:
dummy_target.to_can_async_p = find_default_can_async_p;
... but this means that it is possible for to_can_async_p to return true
while the target does not actually implement to_async.
Tom