From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15537 invoked by alias); 5 Apr 2008 09:29:16 -0000 Received: (qmail 15528 invoked by uid 22791); 5 Apr 2008 09:29:15 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 05 Apr 2008 09:28:58 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.63) (envelope-from ) id 1Ji4hg-0000nO-ER for gdb-patches@sources.redhat.com; Sat, 05 Apr 2008 13:28:55 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Ji4hY-0000nC-NG; Sat, 05 Apr 2008 13:28:44 +0400 From: Vladimir Prus To: Nick Roberts Subject: Re: linux native async mode support Date: Sat, 05 Apr 2008 22:07:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sources.redhat.com References: <200803140810.22883.pedro@codesourcery.com> <200804041546.41673.ghost@cs.msu.su> <18423.16925.181684.296006@kahikatea.snap.net.nz> In-Reply-To: <18423.16925.181684.296006@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804051328.43973.ghost@cs.msu.su> 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 X-SW-Source: 2008-04/txt/msg00117.txt.bz2 On Saturday 05 April 2008 13:10:53 Nick Roberts wrote: > > > The helper functions that you have written for common sequences are a good > > > idea as they need only be updated in one place but the three here are the > > > only ones of their kind (they output an extra "^done" over MI commands like > > > -exec-next). Not really worth a dedicated helper function do you agree? > > > > Why there's extra "^done"? Presently, each command is supposed to have > > either "^running" or "^done", not both. > > There's an extra "^done" because this is a CLI command entered in MI (and > therfore case CLI_COMMAND: of captured_mi_execute_command). There are many > issues here like should we diallow immediate use of CLI commands now and > require explicit use of "-interpreter-exec console"? Probably not -- I don't see any immediate advantage from that. > Then "-interpreter-exec > console next" doesn't emit "(gdb)/n" after "^running" when in asynchronous > mode, so should we remove it from synchronous mode too (as you have suggested)? This prompting is fairly confusing, so it could be that I've confused myself as well, but I think "-interpreter-exec console next" actually *should* print the prompt if the target is async-capable. The reason is that for MI mode, we don't really care about terminal ownership issues, and then should not care about sync_execution, and then this bit of code: else if (sync_execution) { /* Don't print the prompt. We are executing the target in synchronous mode. */ args->action = EXECUTE_COMMAND_SUPPRESS_PROMPT; return; } in captured_mi_execute_command should be removed. In fact, I have a patch-in-progress to do exactly that, and hopefully will be posting it later today. > But these are all MI issues and this test is meant to just be a mark in the > sand for asynchronous mode, and one that I had lying around. For the moment, I > don't really want to work on it further Okay :-) Then, will you mind if I apply this patch either when I'm done with another round of MI testsuite cleanups I'm doing today, or after the ^done is gone, whichever proves more convenient? > > BTW, I'm not even sure that "^done" vs. "^running" + "^done" is so big > > difference that a helper function cannot be introduced. > > The comment suggests that mi_gdb_test will not work but I have not revisited > that since writing the test 18 months or so ago. If true, that could also > make helper functions difficult. Do you happen to remember what race condition the comment mentions? - Volodya