From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9263 invoked by alias); 19 Mar 2008 23:26:49 -0000 Received: (qmail 9255 invoked by uid 22791); 19 Mar 2008 23:26:49 -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; Wed, 19 Mar 2008 23:26:28 +0000 Received: (qmail 5110 invoked from network); 19 Mar 2008 23:26:25 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Mar 2008 23:26:25 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: linux native async mode support Date: Wed, 19 Mar 2008 23:26:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: luisgpm@linux.vnet.ibm.com, Nick Roberts References: <200803140810.22883.pedro@codesourcery.com> <1205943875.32489.10.camel@gargoyle.br.ibm.com> <200803192318.45355.pedro@codesourcery.com> In-Reply-To: <200803192318.45355.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803192326.32361.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00294.txt.bz2 Sorry, forgot to post the sync run without the failure for comparision. A Wednesday 19 March 2008 23:18:45, Pedro Alves wrote: > A Wednesday 19 March 2008 16:24:35, Luis Machado wrote: > > Hi folks, > > > > I've ran the testsuite on PPC to check for regressions due to the async > > patch. The results look good, just the expected regressions and one > > unexpected (mi2-simplerun.exp). > > Thanks both for testing, and thanks Luis for sending me the full logs! > > > mi2-simplerun.exp: > > FAIL: gdb.mi/mi2-simplerun.exp: continue to end (1) > > > > Nick, i still can reproduce the last one constantly. > > > > > 999-exec-continue > > > 999^running > > > Hello, World!callme > > > callme > > > (gdb) > > > 999*stopped,reason="exited-normally" > > > (gdb) > > > FAIL: gdb.mi/mi2-simplerun.exp: continue to end (1) > In sync mode: 999-exec-continue 999^running (gdb) << immediatelly after "^running". Keep reading. Hello, World!callme callme 999*stopped,reason="exited-normally" (gdb) > I've looked at this failure, and what happens is that > in sync mode, gdb prompts "(gdb)" immediatelly > after printing "^running", while in async mode, > "^running" is output first, and only when "run" cli command > actually completes, the "(gdb) " is output. Like so: > > mi_execute_command > captured_mi_execute_command > mi_execute_async_cli_command > mi_cmd_execute > mi_cmd_exec_run > mi_execute_async_cli_command > sets up continuation for "*stopped", if async mode. > execute_command > (...) > run_command_1 > target_create_inferior > proceed > prints ("gdb") before exiting. > > later, when inferior exits, the mi_exec_async_cli_cmd_continuation is > called, > > which prints that part: > > > 999*stopped,reason="exited-normally" > > > (gdb) > > Here's a bit of current code: > > enum mi_cmd_result > mi_execute_async_cli_command (char *mi, char *args, int from_tty) > { > struct cleanup *old_cleanups; > char *run; > char *async_args; > > if (target_can_async_p ()) > { > async_args = (char *) xmalloc (strlen (args) + 2); > make_exec_cleanup (free, async_args); > strcpy (async_args, args); > strcat (async_args, "&"); > run = xstrprintf ("%s %s", mi, async_args); > make_exec_cleanup (free, run); > add_continuation (mi_exec_async_cli_cmd_continuation, NULL); > old_cleanups = NULL; > } > else > { > run = xstrprintf ("%s %s", mi, args); > old_cleanups = make_cleanup (xfree, run); > } > > if (!target_can_async_p ()) > { > /* NOTE: For synchronous targets asynchronous behavour is faked by > printing out the GDB prompt before we even try to execute the > command. */ > if (last_async_command) > fputs_unfiltered (last_async_command, raw_stdout); > fputs_unfiltered ("^running\n", raw_stdout); > fputs_unfiltered ("(gdb) \n", raw_stdout); <<<<< sync mode > prints it early. > gdb_flush (raw_stdout); > } > else > { > /* FIXME: cagney/1999-11-29: Printing this message before > calling execute_command is wrong. It should only be printed > once gdb has confirmed that it really has managed to send a > run command to the target. */ > if (last_async_command) > fputs_unfiltered (last_async_command, raw_stdout); > fputs_unfiltered ("^running\n", raw_stdout); <<<<< async mode > defers the "(gdb)" > printing } > > execute_command ( /*ui */ run, 0 /*from_tty */ ); > > (...) > } > > So, -exec-run, in async mode, is turned into CLI's "run &", which ends > up in run_command_1. At the end of it, after calling > target_create_inferior and friends, we do proceed. So at this point the > inferior as already started running, and we haven't printed "(gdb)" yet. > We'll only print *after* creating the inferior and proceed'ing. There you > have the difference to sync mode. It's really a timing issue, and that's > why I can't reproduce -- it is timing/host sensitive. So this means this > problem isn't related to my patch, but it's a general async issue, that may > be visible too in > "target async" connected to a gdbserver for example. Although > since we're running over a slower link there, nobody was probably seeing > it. I don't know enough MI to say if this is according to the spec > or not, but it feels like a testsuite deficiency, is it not? -- Pedro Alves