Re: [RFC 05/32] add target method delegation

[Tom Tromey <tromey at redhat dot com>]

>> MUST UPDATE

Pedro> Yes, must.  :-)

Hah, thanks for noticing that.
That was just a note to myself that I needed to update the ChangeLog
and/or description for that patch.
I've fixed it on my branch.

>> -record_full_can_async_p (struct target_ops *ops)
[...]
>> -record_full_is_async_p (struct target_ops *ops)

Pedro> I think these were and still are necessary, due to how
Pedro> find_default_target_can_async_p etc. is installed in the dummy target.
Pedro> E.g., when debugging with the record-core target, without this, I
Pedro> think we'll end up hitting the dummy target, because the core_ops
Pedro> target delegates these methods.  That means we'll end up asking e.g.,
Pedro> the GNU/Linux target whether it can async, while that isn't the
Pedro> process_stratum target that is open.

I finally sat down to think about this, and I agree.
I will restore these.

I probably won't have an updated patch series until Feb at this point.

Pedro> This made me realize another issue with the
Pedro> find_default_target_can_async_p (or really all find_default_...)
Pedro> being installed in the dummy/default target.  E.g., considering a
Pedro> configuration that includes both remote-sim, and a native target
Pedro> that can run.  When connected to the sim, we'll end up calling
Pedro> that method in the default run target which is wrong.

I may end up having to clean up these methods a bit for multi-target
anyhow.  I mean, I know I have to do something, due to the previously
mentioned "type-vs-instance" problem these methods have; but whether or
not it would necessarily fix the above, I don't know.

Tom