From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26872 invoked by alias); 4 Oct 2015 14:31:04 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 26852 invoked by uid 89); 4 Oct 2015 14:31:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f50.google.com Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com) (209.85.220.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 04 Oct 2015 14:30:59 +0000 Received: by padhy16 with SMTP id hy16so10438952pad.1 for ; Sun, 04 Oct 2015 07:30:57 -0700 (PDT) X-Received: by 10.68.132.234 with SMTP id ox10mr32914822pbb.128.1443969057607; Sun, 04 Oct 2015 07:30:57 -0700 (PDT) Received: from lanh ([171.232.94.118]) by smtp.gmail.com with ESMTPSA id uc1sm22496930pab.20.2015.10.04.07.30.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Oct 2015 07:30:56 -0700 (PDT) Received: by lanh (sSMTP sendmail emulation); Sun, 04 Oct 2015 21:31:37 +0700 Date: Sun, 04 Oct 2015 14:31:00 -0000 From: Duy Nguyen To: gdb@sourceware.org Subject: reduce stop time at attach& Message-ID: <20151004143137.GA29729@lanh> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00011.txt.bz2 Attaching non-stop + async on extended-remote target could be slow. In my tests it could take up to half a second, which is too long for some applications where they are expected to have execution time every 50ms or so, otherwise things (in other parts of the system) break down. I wonder if we can reduce stop time in this case? >From what I can see (and I know very little about gdb or debuggers in general), in remote non-stop/async mode, we can resume execution before doing post-attach actions. This keeps stop time down to about 15ms in my tests. The only problematic part is breakpoint installation, which maybe could be done manually after the user chooses a safe thread to stop. Something like this patch below demonstrates it. Do you think there is any problem with it? Another approach I'm toying with is allow the user to select a thread to stop. This will be an idle thread, created for gdb to stop and nothing else. So we could stop the first thread, lookup thread-db, then resume it and stop the user-requested thread before doing the rest of attaching. Or we could stop the user-requested thread right away. Either way seems to be more complicated than just resuming as soon as possible. -- 8< -- diff --git a/gdb/infcmd.c b/gdb/infcmd.c index 54aa1ef..7470a19 100644 --- a/gdb/infcmd.c +++ b/gdb/infcmd.c @@ -420,7 +420,8 @@ post_create_inferior (struct target_ops *target, int from_tty) stop_pc = 0; TRY { - stop_pc = regcache_read_pc (get_current_regcache ()); + if (!target_is_async_p ()) + stop_pc = regcache_read_pc (get_current_regcache ()); } CATCH (ex, RETURN_MASK_ERROR) { @@ -2609,19 +2610,9 @@ proceed_after_attach (int pid) do_cleanups (old_chain); } -/* attach_command -- - takes a program started up outside of gdb and ``attaches'' to it. - This stops it cold in its tracks and allows us to start debugging it. - and wait for the trace-trap that results from attaching. */ - static void -attach_command_post_wait (char *args, int from_tty, int async_exec) +post_attach (int from_tty) { - struct inferior *inferior; - - inferior = current_inferior (); - inferior->control.stop_soon = NO_STOP_QUIETLY; - /* If no exec file is yet known, try to determine it from the process itself. */ if (get_exec_file (0) == NULL) @@ -2636,6 +2627,20 @@ attach_command_post_wait (char *args, int from_tty, int async_exec) target_post_attach (ptid_get_pid (inferior_ptid)); post_create_inferior (¤t_target, from_tty); +} + +/* attach_command -- + takes a program started up outside of gdb and ``attaches'' to it. + This stops it cold in its tracks and allows us to start debugging it. + and wait for the trace-trap that results from attaching. */ + +static void +attach_command_post_wait (char *args, int from_tty, int async_exec) +{ + struct inferior *inferior; + + inferior = current_inferior (); + inferior->control.stop_soon = NO_STOP_QUIETLY; if (async_exec) { @@ -2656,9 +2661,11 @@ attach_command_post_wait (char *args, int from_tty, int async_exec) proceed ((CORE_ADDR) -1, GDB_SIGNAL_DEFAULT); } } + post_attach (from_tty); } else { + post_attach (from_tty); /* The user requested a plain `attach', so be sure to leave the inferior stopped. */ -- 8< --