From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40643 invoked by alias); 4 Mar 2015 19:45:38 -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 40632 invoked by uid 89); 4 Mar 2015 19:45:37 -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_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 04 Mar 2015 19:45:36 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t24JjWoX014786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 4 Mar 2015 14:45:32 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t24JjUdo032594; Wed, 4 Mar 2015 14:45:31 -0500 Message-ID: <54F760DA.5050909@redhat.com> Date: Wed, 04 Mar 2015 19:45:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Simon Marchi , gdb-patches@sourceware.org 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> <54F75E7A.9060308@ericsson.com> In-Reply-To: <54F75E7A.9060308@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00138.txt.bz2 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