From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81075 invoked by alias); 18 May 2016 14:45:29 -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 81046 invoked by uid 89); 18 May 2016 14:45:28 -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=79 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; Wed, 18 May 2016 14:45:18 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [binutils-gdb] Fix double prompt output after run control MI commands with mi-async on (PR 20045) From: sergiodj+buildbot@sergiodj.net To: gdb-testers@sourceware.org Message-Id: <28addb40c77db5a5873172b62b6b7b43e5e05014@gdb-build> Date: Wed, 18 May 2016 14:45:00 -0000 X-SW-Source: 2016-q2/txt/msg02906.txt.bz2 *** TEST RESULTS FOR COMMIT 28addb40c77db5a5873172b62b6b7b43e5e05014 *** Author: Simon Marchi Branch: master Commit: 28addb40c77db5a5873172b62b6b7b43e5e05014 Fix double prompt output after run control MI commands with mi-async on (PR 20045) When you use a run control command (-exec-run, -exec-continue, -exec-next, ...) with mi-async on, an extra (gdb) prompt is displayed: -exec-continue ^running *running,thread-id="all" (gdb) (gdb) It doesn't seem to be a big problem for front-ends, since this behavior started in gdb 7.9 and we haven't heard anything about that. However, it caused me some trouble while writing a test for PR 20039 [1]. The problem comes from an extra (gdb) prompt that we write when running in mi-async off mode to emulate a past buggy behavior. When executing a run control command synchronously, previous gdbs always printed a prompt right away, even though they are not ready to accept new MI commands until the target stops. Only at this time should they display a prompt. But to keep backwards compatibility apparently, we print it anyway. Since commit 198297aaf, the condition that decides whether we should print that "bogus" prompt or not has become true, even when running with mi-async on. Since we already print a prompt at the end of the asynchronous command execution, it results in two prompts for one command. The proposed fix is to call target_can_async_p instead of target_is_async_p, to make the condition: if (!target_can_async_p () || sync_execution) ... show prompt ... That shows the prompt if we are emulating a synchronous command on top of an asynchronous target (sync_execution) or if the target simply can't run asynchronously (!target_can_async_p ()). Note that this code is changed and this bug fixed by Pedro's separate console series, but I think it would be nice to have it fixed in the mean time. I ran the gdb.mi directory of the testsuite with mi-async on and off, I didn't see any regressions. gdb/ChangeLog: * mi/mi-main.c (mi_on_resume): Call target_can_async_p instead of target_is_async_p. [1] https://sourceware.org/ml/gdb-patches/2016-05/msg00075.html