From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12305 invoked by alias); 10 Apr 2008 17:41:47 -0000 Received: (qmail 12297 invoked by uid 22791); 10 Apr 2008 17:41:46 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 Apr 2008 17:41:29 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 48E992A9F7B; Thu, 10 Apr 2008 13:41:27 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lY20yXf55Pum; Thu, 10 Apr 2008 13:41:27 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id E35B12A9DEB; Thu, 10 Apr 2008 13:41:26 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 942DAE7ACD; Thu, 10 Apr 2008 10:41:24 -0700 (PDT) Date: Thu, 10 Apr 2008 18:00:00 -0000 From: Joel Brobecker To: gdb@sourceware.org, Nick Roberts Subject: Re: Non-stop debugging and automatically stopping the target Message-ID: <20080410174124.GA7163@adacore.com> References: <20080410141711.GA22694@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080410141711.GA22694@caradoc.them.org> User-Agent: Mutt/1.4.2.2i 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 X-SW-Source: 2008-04/txt/msg00083.txt.bz2 > The general issue is this: should GDB implicitly stop the target? I think some commands are more "special" than others, and indeed backtrace is one of those. > Then of course there are race conditions. Even if we can read memory > non-intrusively, we probably can't get a consistent snapshot of memory > for long enough to generate a backtrace; the current function will > return in the middle of the unwinding process. So for backtrace, the > target is going to have to stop. Yes, I don't see a way out of stopping the inferior if we want to be able to reliably compute the backtrace. But even for plain memory reads (such as "x/x ADDR" or just plain "print VAR"), there are also possible race conditions. The subject of this thread says "non-stop" mode, so does it mean that in "all-stop" mode we're assuming that the target program is not time- sensitive, and so we'll always pause it? In which case, I assume users of the "non-stop" mode are in fact worried about time spent in suspended mode. I think it's important to understand who are going to be the typical users of the non-stop mode. Assuming I am correct about the distinction, we could decide that all these commands (backtrace, x, etc) do in fact implicitly interrupt the inferior when in all-stop mode. If the typical user of the non-stop mode is in fact worried about not affecting the timing of his application, I allow most commands that we expect to be processed quickly (print VAR, x/x, etc) to be performed while running if the target allows it - knowing that the output could be corrupted if the target was writing the data we're reading at the same time. For the backtrace, I'm unsure. We could try experimenting with NOT stopping the target and see if we can make it produce something correct at least a decent proportion of the time. I don't see any problem with disallowing the backtrace command in non-stop mode, or making it implicitly stop the target (in that case, I would suggest the use of an option to protect its use). Requiring that the user suspend the target himself in order to being able to get a backtrace is not that attractive, IMO. In that case, the user would have to perform a sequence of 3 steps (suspend; backtrace; resume) instead of just one command, which would probably take more time than if the backtrace command did the suspend/resume itself. -- Joel