From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44058 invoked by alias); 4 May 2016 19:27:43 -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 43627 invoked by uid 89); 4 May 2016 19:27:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=tty, maint, bothered 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 May 2016 19:27:41 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0C8E47AE82; Wed, 4 May 2016 19:27:40 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u44JRcOw024479; Wed, 4 May 2016 15:27:39 -0400 Subject: Re: [PATCH] Add mi-threads-interrupt.exp test (PR 20039) To: Simon Marchi , gdb-patches@sourceware.org References: <1462305612-16493-1-git-send-email-simon.marchi@ericsson.com> <5983d4d2-016a-8020-c109-cb7ea2cfd179@redhat.com> <572A399C.60902@ericsson.com> From: Pedro Alves Message-ID: <1c2b69f6-6bd0-862e-cbce-e1be4dd7df15@redhat.com> Date: Wed, 04 May 2016 19:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <572A399C.60902@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-05/txt/msg00063.txt.bz2 On 05/04/2016 07:04 PM, Simon Marchi wrote: > Why would it make sense to set async on in a board file? My understanding is > that the board file defines the debug target side of things, but the fact that MI > is sync or async (or that we use MI at all) is not decided by the debug target. Either setting GDBFLAGS on the board file or on the command line, it's really the same thing: an expedient way to run the whole testsuite in a certain mode. I've found it quite useful over the years, while working on e.g., "set breakpoints always-inserted on", or when doing all the work toward making "set target-async on" the default. In either case, this was not a setting that users really should really need to be toggling themselves. > I would think that it's up to the tests to set async however they want it, > depending on what they test. In this particular case, wouldn't it be better > to run both the test in sync and async modes, as we do often for non-stop? A bit of history here. We nowadays have two distinct commands: #1 - "set mi-async on" #2 - "maint set target-async on" The mi-async command makes all MI execution commands be background commands. That is, e.g., "-exec-continue" turns into "continue&" rather than "continue". (Plus some other minor differences.) It doesn't make much sense for MI execution commands to ever be sync, but, frontends that are not prepared for async would break, thus the need for the switch. The "maint set target-async on" command changes the way the target backend works, but other than _enabling_ accessing to background commands, it should have no user-visible behavior. The only reason for the command to exist, is convenience, for emulating targets that don't do async yet, on GNU/Linux. While a few releases back we had a single "set target-async" that conflicted both #1 and #2. And at the time, because that command actually changed how the target_ops behaves, it was sort of a maintenance command in disguise, it didn't make sense to change _every_ test in the testsuite to try both "set target-async on/off". So years ago (circa 2007/2008, I believe), what we did was make it possible to force "set target-async on", and run the testsuite that way. And then since MI changed output when tested that way, we made the testsuite cope. And then nobody bothered yet to make all _MI_ tests run with "set mi-async on/off", while leaving all CLI tests alone at the same time. > > So, for example: > > proc test_continue_interrupt { async } { > with_test_prefix "async=$async" { > ... > } > } > > foreach async {on off} { > test_continue_interrupt $async > } > > It hacked the test quickly, and it shouldn't be too hard to do. > Yeah. But in reality, we should really be doing that to all MI tests. For the console series, I'm adding another test axis to consider, which is to run all MI tests with MI forced to a separate tty. This has been _very_ convenient to catch problems. For now, I'm adding a way to force that from the command line, but I could see us run all MI tests always in both normal MI, and separate MI modes. It's easy to explode the number of testing axes though... This test in particular though, maybe it just doesn't make sense to run in async mode at all, as sending a ctrl-c to gdb in that case _should_ result in a Quit. Thanks, Pedro Alves