From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4568 invoked by alias); 19 Mar 2008 23:19:03 -0000 Received: (qmail 4488 invoked by uid 22791); 19 Mar 2008 23:19:03 -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:18:45 +0000 Received: (qmail 4639 invoked from network); 19 Mar 2008 23:18:36 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Mar 2008 23:18:36 -0000 From: Pedro Alves To: luisgpm@linux.vnet.ibm.com Subject: Re: linux native async mode support Date: Wed, 19 Mar 2008 23:19:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: Nick Roberts , gdb-patches@sourceware.org References: <200803140810.22883.pedro@codesourcery.com> <18400.36720.580645.362838@kahikatea.snap.net.nz> <1205943875.32489.10.camel@gargoyle.br.ibm.com> In-Reply-To: <1205943875.32489.10.camel@gargoyle.br.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803192318.45355.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/msg00293.txt.bz2 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) > > 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