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

[Pedro Alves <palves@redhat.com>]

On 03/04/2015 07:35 PM, Simon Marchi wrote:

> 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.

Sorry about that.  I was interrupted midway writing that email,
and looks like I didn't glue things the best I could...  Let
me expand.

Here what I was thinking was, it might look like that the fix
should just be to make run_one_inferior pass the mi_async
variable directly, like:

 -    mi_execute_cli_command (run_cmd, mi_async_p (),
 +    mi_execute_cli_command (run_cmd, mi_async,
			      mi_async_p () ? "&" : NULL);

But, that would make "set mi-async on; -exec-run" with a target
that can't do async error out with "Asynchronous execution not
supported on this target", which is not how MI is documented to behave.
The "mi_async && target_can_async_p()" checks inside mi_async_p(), and
its use here mimic older GDBs behavior before target-async
was the default.  IOW, in older gdb's, if you did "set target-async on"
and then -exec-run/continue/step/whatever with a non-async target,
gdb would just ignore the target-async request and do a
synchronous run.

Let me know whether it's better now.  :-)

Thanks,
Pedro Alves