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: Simon Marchi <simon dot marchi at ericsson dot com>
- To: Pedro Alves <palves at redhat dot com>, <gdb-patches at sourceware dot org>
- Date: Wed, 4 Mar 2015 14:35:22 -0500
- 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>
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