From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31330 invoked by alias); 10 Mar 2008 10:02:47 -0000 Received: (qmail 31322 invoked by uid 22791); 10 Mar 2008 10:02:47 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Mar 2008 10:02:19 +0000 Received: (qmail 15834 invoked from network); 10 Mar 2008 10:02:17 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Mar 2008 10:02:17 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: [RFA] Async mode fixes. Date: Mon, 10 Mar 2008 10:02:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sources.redhat.com References: <200803051027.29575.vladimir@codesourcery.com> <200803101057.51401.vladimir@codesourcery.com> <18388.64350.993440.984898@kahikatea.snap.net.nz> In-Reply-To: <18388.64350.993440.984898@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: <200803101302.15250.vladimir@codesourcery.com> 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-03/txt/msg00090.txt.bz2 On Monday 10 March 2008 12:11:58 Nick Roberts wrote: > > Likewise, I think it's better to always use async mode, > > if the target supports it. We're not at the point when we can do > > it -- even with my patch, 'target async' has a couple of extra > > failures relatively to 'target remote', and I never tried getting > > test results for linux native -- but I think having async mode > > always on should be end goal. > > The patch isn't perfect, e.g., you say: > > I get the following with my patch: > > (gdb) > -interpreter-exec console continue > ~"Continuing.\n" > ^running > *stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",..... > > but that should be: > > (gdb) > -interpreter-exec console continue > ~"Continuing.\n" > ^running > (gdb) > *stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",..... > > because in mi_execute_command, args.action == EXECUTE_COMMAND_SUPRESS_PROMPT > when it should be EXECUTE_COMMAND_DISPLAY_PROMPT. This in turn is because > sync_execution is 1 when it should be 0. Note that in Apple's code > sync_execution doesn't get toggled by async_enable/disable_stdin, You mean 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_SUPRESS_PROMPT; return; } ? I actually planned to remove it without further ado, after this async patch goes in. My reasoning is that the current behaviour is just bizarre. For sync target, any exec commands results in ^running (gdb) whereas for async target, due to above fragment, you can sometimes not get a prompt -- and this is backward. Of course, this code only deals with printing the prompt, whereas we still have the bigger issue -- namely that if we execute "continue" using -interpreter-exec, then GDB does not accept the input while continue runs, and -exec-interrupt does not work. Apple branch fixes that by not setting sync_execution inside async_disable_stdin, but I find the fix suspect -- if we give up terminal to inferior and then try to read something, I'm not sure it will work. It does work with "target async", but target async does not actually mess with terminal. One solution is probably to never disable stdin when an external tty is used for program output. Or to never disable stdin when top-level interpreter is MI. I must admit I don't know the right solution, yet. - Volodya