From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29365 invoked by alias); 10 Apr 2008 14:17:35 -0000 Received: (qmail 29301 invoked by uid 22791); 10 Apr 2008 14:17:34 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 Apr 2008 14:17:13 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 0A093980F7; Thu, 10 Apr 2008 14:17:12 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id B223398060; Thu, 10 Apr 2008 14:17:11 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JjxaR-00063R-2K; Thu, 10 Apr 2008 10:17:11 -0400 Date: Thu, 10 Apr 2008 17:59:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Cc: Nick Roberts Subject: Non-stop debugging and automatically stopping the target Message-ID: <20080410141711.GA22694@caradoc.them.org> Mail-Followup-To: gdb@sourceware.org, Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes 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/msg00082.txt.bz2 This is a followup to Nick's backtrace patch of April 1st, which temporarily stops the target to generate a backtrace. It raises an issue which Pedro and Volodya have also noticed, and I think we should discuss it before we commit to any option. The general issue is this: should GDB implicitly stop the target? For instance, consider memory reads. Reading memory while the target is running divides roughly into these types: - Can't do it. GDB has to stop the target first. Reading memory via ptrace is in this category. - Can do it, mildly intrusively (5ms - 10ms delay in execution). Some embedded debug interfaces are like this; the CPU is used to assist the debug interface, so while it's processing debug requests the target does not make progress. - Can do it, as long as some other thread is stopped. Ptrace on a multi-threaded program is in this category, generally. It doesn't matter which thread is stopped. - Can do it, pretty much transparently to the target. Some embedded debug interfaces are like this; so is reading memory via /proc on a multi-processor Linux system. 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. Under which of these conditions should we allow the user to say "backtrace" or "x/x ADDR", and under which should we require the user (or front end) to say "stop thread 3; backtrace; continue thread 3"? I am a little worried about making backtrace always work even if it has to pause the target; some targets should not be paused without explicit request, if they're time sensitive. Or maybe time-sensitive should be a setting the user or front end has to make. -- Daniel Jacobowitz CodeSourcery