From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24945 invoked by alias); 4 Mar 2015 10:18:25 -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 24936 invoked by uid 89); 4 Mar 2015 10:18:25 -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 10:18:18 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t24AIE79021862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 4 Mar 2015 05:18:14 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t24AICqr016613; Wed, 4 Mar 2015 05:18:13 -0500 Message-ID: <54F6DBE4.6080206@redhat.com> Date: Wed, 04 Mar 2015 10:18: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> In-Reply-To: <1425419133-7843-1-git-send-email-simon.marchi@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00120.txt.bz2 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 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: On some targets, @value{GDBN} is capable of processing MI commands even while the target is running. This is called @dfn{asynchronous command execution} (@pxref{Background Execution}). The frontend may specify a preferrence for asynchronous execution using the @code{-gdb-set mi-async 1} command, which should be emitted before either running the executable or attaching to the target. After the frontend has started the executable or attached to the target, it can find if asynchronous execution is enabled using the @code{-list-target-features} command. I think it'd be cleaner if when "set mi-async on" (the new spelling of "set target-async on", it's just an alias) is in effect with a target that really CANNOT async, we'd still make -exec-run try to run in async mode, which would error out just like if the user does "run&" on such a target, but alas, that's not how previous gdb releases worked. We'd need to hear from frontend developers whether that's a desirable change. > > I added a small testcase that I copied from mi-async.exp. Please > indicate if you think it should be integrated to an existing test rather > than in a new test. > > I have two questions regarding the test: > > - Why do we have mi_expect_stop and mi_expect_interrupt? It seems like > the functionality of _interrupt could be integrated in _stop. So we can cope with differences like: ... > - The signal reported when interrupting a thread changes when in non-stop vs all-stop: > > non-stop: *stopped,reason="signal-received",signal-name="0",signal-meaning="Signal 0",.. > all-stop: *stopped,reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",... ... these? > > As a consequence, mi_expect_interrupt only works with non-stop. Could you fix it? I think expecting both signals would be fine. > +#include > + > +int main () int main (void) > +# The purpose of this test if to verify that -exec-run with mi-async on > +# results in asynchronous execution (PR 18077). > + > +# The plan is for async mode to become the default but toggle for now. > +set saved_gdbflags $GDBFLAGS > +set GDBFLAGS [concat $GDBFLAGS " -ex \"set mi-async on\""] > + Can you make this a regular "-gdb-set mi-async", after GDB is started, please? (You'll then need to call mi_detect_async too.) > +load_lib mi-support.exp > + > +gdb_exit > +if [mi_gdb_start] { > + continue > +} > + > +standard_testfile > + > +if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } { > + untested mi-async.exp > + return -1 > +} > + > +mi_delete_breakpoints > +mi_gdb_reinitialize_dir $srcdir/$subdir > +mi_gdb_load ${binfile} > + > +# Necessary for mi_expect_interrupt to work, as the reported signal is not the > +# same in all-stop. > +mi_gdb_test "-gdb-set non-stop 1" ".*" > + > +proc linux_async_run_test {} { Drop the "linux" prefix, please. > + global mi_gdb_prompt > + global hex These don't appear to be used. > + > + mi_run_cmd > + mi_gdb_test "123-exec-interrupt --all" "123\\^done" "send interrupt command" > + mi_expect_interrupt "expect interrupt" > +} > + > +linux_async_run_test > + > +mi_gdb_exit > + > +set GDBFLAGS $saved_gdbflags > + > +return 0 > Thanks, Pedro Alves