From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49262 invoked by alias); 17 May 2016 22:13:40 -0000 Mailing-List: contact gdb-testers-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-testers-owner@sourceware.org Received: (qmail 49239 invoked by uid 89); 17 May 2016 22:13:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=boards, U*simon.marchi, simonmarchiericssoncom, sk:simonm X-HELO: kwanyin.sergiodj.net Received: from kwanyin.sergiodj.net (HELO kwanyin.sergiodj.net) (176.31.208.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 17 May 2016 22:13:29 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [binutils-gdb/gdb-7.11-branch] Fix -exec-run not running asynchronously with mi-async on (PR gdb/18077) From: sergiodj+buildbot@sergiodj.net To: gdb-testers@sourceware.org Message-Id: Date: Tue, 17 May 2016 22:13:00 -0000 X-SW-Source: 2016-q2/txt/msg02794.txt.bz2 *** TEST RESULTS FOR COMMIT b5f0db46b3057bcb64243e7da0943717abd6459b *** Author: Simon Marchi Branch: gdb-7.11-branch Commit: b5f0db46b3057bcb64243e7da0943717abd6459b Fix -exec-run not running asynchronously with mi-async on (PR gdb/18077) When doing -exec-run on a freshly started GDB, the only target on the target stack at the time the dummy one. When mi_async_p is called to know whether the run should be async, it queries whether the current target (dummy) supports async, and the answer is no. The fix is to make the code query the target that will be used for the run, which is not necessarily the current target. No regressions in the gdb.mi directory using the unix, native-gdbserver and native-extended-gdbserver boards. The test doesn't pass when forcing maint set target-async off, obviously, since it makes mi-async have no effect. It doesn't seem like other tests are checking for that eventuality, so I didn't in the new test. gdb/ChangeLog: * mi/mi-main.c (run_one_inferior): Use run target to determine whether to run async or not. (mi_cmd_exec_run): Likewise. gdb/testsuite/ChangeLog: * gdb.mi/mi-async-run.exp: New file. * gdb.mi/mi-async-run.c: New file.