Re: [PATCH] mi_async_p: Use the default run target (PR gdb/18077)

[Simon Marchi <simon.marchi@ericsson.com>]

On 03/04/2015 02:32 PM, Pedro Alves wrote:
> On 03/04/2015 07:29 PM, Simon Marchi wrote:
>> Hi Pedro,
>>
>> On 03/04/2015 05:18 AM, Pedro Alves wrote:
>>>> On 03/03/2015 09:45 PM, Simon Marchi wrote:
>>>>>> When using -exec-run in mi-async mode on a fresh gdb launch, we can see
>>>>>> that it is not actually done asynchronously.
>>>>>>
>>>>>> The problem is that when we issue -exec-run, the linux native target is
>>>>>> not pushed yet. So when the code in mi_cmd_exec-run checks if we support
>>>>>> async (by calling mi_async_p), tdefault_can_async_p from the dummy
>>>>>> target answers 0.
>>>>>>
>>>>>> I am not certain of the conceptual correctness of this solution, but it
>>>>>> seems to work. It changes mi_async_p so that it uses find_run_target()
>>>>>> instead of using the current_target. When -exec-run is used before the
>>>>>> native target is pushed, mi_async_p will now report that the target that
>>>>>> will eventually be used for running supports async, instead of saying
>>>>>> that the current target (dummy) does not.
>>>>
>>>> This is not correct.  E.g., when some target is already pushed,
>>>> and it's one that does support async, but can't "run", in other places
>>>> that we use mi_async_p we should be consulting the already connected
>>>> target, not fallback to the run target.
>>>> Please make sure to test with native and gdbserver in both
>>>> remote and extended remote modes, to cover different modes of
>>>> operation, though you're likely not seeing an issue with
>>>> "target remote", which does not support "run", just because that
>>>> does implement t->to_create_inferior, but that's for
>>>> extended-remote, really (see find_run_target).
>>>>
>>>> I think we need to make run_one_inferior itself check whether the
>>>> run target can async, instead of using mi_async_p() there.  Likewise
>>>> for
>> Is it possible that the last paragraph and the next one are missing some
>> parts? I'd like to have the complete information before I try to answer
>> something intelligible :).
> 
> Just nevermind that "Likewise ...".  I was going to
> say "Likewise for attach", but then I noticed that "-exec-attach" always
> maps to "attach", but missed deleting that bit.  :-)
> 
> Let me know if things still aren't clear.
> 
> Thanks,
> Pedro Alves

There is still the following paragraph that looks like it was split or
something:

> Note that the "mi_async && target_can_async_p()" checks intend to
> mimic GDB's behavior before target-async was the default.  In order
> gdb's, if you did "set target-async on" and then
> -exec-run/continue/step/whatever, gdb would just ignore the target-async
> request.  This is actually documented:

I think I get the gist of it, but I am asking just in case.

Simon