This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] mi_async_p: Use the default run target (PR gdb/18077)
- From: Pedro Alves <palves at redhat dot com>
- To: Simon Marchi <simon dot marchi at ericsson dot com>, gdb-patches at sourceware dot org
- Date: Wed, 04 Mar 2015 19:45:30 +0000
- Subject: Re: [PATCH] mi_async_p: Use the default run target (PR gdb/18077)
- Authentication-results: sourceware.org; auth=none
- References: <1425419133-7843-1-git-send-email-simon dot marchi at ericsson dot com> <54F6DBE4 dot 6080206 at redhat dot com> <54F75D10 dot 1080904 at ericsson dot com> <54F75DDC dot 2050406 at redhat dot com> <54F75E7A dot 9060308 at ericsson dot 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