From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115854 invoked by alias); 4 Mar 2015 19:35:27 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 115842 invoked by uid 89); 4 Mar 2015 19:35:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: usevmg20.ericsson.net Received: from usevmg20.ericsson.net (HELO usevmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 04 Mar 2015 19:35:25 +0000 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9E.1D.16061.4C907F45; Wed, 4 Mar 2015 14:33:57 +0100 (CET) Received: from [142.133.110.232] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.89) with Microsoft SMTP Server id 14.3.210.2; Wed, 4 Mar 2015 14:35:22 -0500 Message-ID: <54F75E7A.9060308@ericsson.com> Date: Wed, 04 Mar 2015 19:35:00 -0000 From: Simon Marchi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pedro Alves , Subject: Re: [PATCH] mi_async_p: Use the default run target (PR gdb/18077) References: <1425419133-7843-1-git-send-email-simon.marchi@ericsson.com> <54F6DBE4.6080206@redhat.com> <54F75D10.1080904@ericsson.com> <54F75DDC.2050406@redhat.com> In-Reply-To: <54F75DDC.2050406@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00137.txt.bz2 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