This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC 05/32] add target method delegation
- From: Pedro Alves <palves at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 14 Jan 2014 12:32:55 +0000
- Subject: Re: [RFC 05/32] add target method delegation
- Authentication-results: sourceware.org; auth=none
- References: <1389640367-5571-1-git-send-email-tromey at redhat dot com> <1389640367-5571-6-git-send-email-tromey at redhat dot com>
On 01/13/2014 07:12 PM, Tom Tromey wrote:
> MUST UPDATE
Yes, must. :-)
> -
> -static int
> -record_full_can_async_p (struct target_ops *ops)
> -{
> - /* We only enable async when the user specifically asks for it. */
> - return target_async_permitted;
> -}
> -
> -static int
> -record_full_is_async_p (struct target_ops *ops)
> -{
> - /* We only enable async when the user specifically asks for it. */
> - return target_async_permitted;
> -}
> -
I think these were and still are necessary, due to how
find_default_target_can_async_p etc. is installed in the dummy target.
E.g., when debugging with the record-core target, without this, I
think we'll end up hitting the dummy target, because the core_ops
target delegates these methods. That means we'll end up asking e.g.,
the GNU/Linux target whether it can async, while that isn't the
process_stratum target that is open.
This made me realize another issue with the find_default_target_can_async_p
(or really all find_default_...) being installed in the dummy/default
target. E.g., considering a configuration that includes both remote-sim,
and a native target that can run. When connected to the sim, we'll
end up calling that method in the default run target which is wrong.
But for the scope of this series, I think it'll suffice to leave
those record-full methods in place for now.
Otherwise looks good to me.
--
Pedro Alves