From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25714 invoked by alias); 14 Jun 2006 19:55:52 -0000 Received: (qmail 25705 invoked by uid 22791); 14 Jun 2006 19:55:50 -0000 X-Spam-Check-By: sourceware.org Received: from potter.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 Jun 2006 19:55:48 +0000 Received: (qmail 1519 invoked from network); 14 Jun 2006 19:55:46 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Jun 2006 19:55:46 -0000 To: gdb-patches@sourceware.org Subject: Re: RFC: Don't kill the program after "file" References: <20060613205014.GA20822@nevyn.them.org> From: Jim Blandy Date: Wed, 14 Jun 2006 19:55:00 -0000 In-Reply-To: <20060613205014.GA20822@nevyn.them.org> (Daniel Jacobowitz's message of "Tue, 13 Jun 2006 16:50:14 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00220.txt.bz2 Daniel Jacobowitz writes: > I talked with Jim about this. He wasn't entirely happy with discarding > the prompt for native debugging, where it traditionally makes sense; we > didn't quite make it to an agreement on what ought to happen. He > suggested adding a "process-oriented" flag to target vectors. For a > process oriented target (i.e. one which can handle "run" and "kill" and > so forth) it makes sense to offer to kill at this point; for > board oriented targets it makes less sense. Another thing which just > occured to me would be to make the file command succeed if you say "n" > at the query. I don't think this patch should be blocked on reaching a consensus on this larger design issue, but I would like to expand on the thought a bit. We certainly want GDB's commands to work consistently, regardless of architecture, whether we're working remotely or locally, and so on. However, the distinction between a target that creates a new process each time you 'run' (like native Unix debugging) versus a target like a simple board without a kernel or memory management, where you're simply manipulating registers and memory that are always there, can't really be concealed from the user. In the 'process' case, there really is no register set for GDB to operate on until you start the program running. Commands like 'print $pc' and 'where' need to produce an error. $ gdb hello GNU gdb Red Hat Linux (6.3.0.0-1.84rh) ... (gdb) print $pc No registers. (gdb) where No stack. (gdb) Commands like 'print a', where a is a global or static variable, read their data directly to the executable file when there's no process, so they can work even before a 'run'. But in the non-process case, where GDB is talking to a system whose state persists between program runs, there are always registers and memory to play with; a 'load' just writes to memory to put the program in place, and does some initialization like setting the PC. There's no reason to prohibit things like register manipulation and stack backtraces until something like a 'run' is done. Note that this is not really a "native vs. remote" distinction. If the remote end were a gdbserver running on a Linux machine, it would make perfect sense for that remote target to employ a 'process' model. (I think 'extended remote' mode works this way, essentially, but there are details I'm confused about.) The distinction has to do with how programs are run, not with our communications protocol. GDB must expose this distinction the user; we can't unify the two cases. To make the persistent case behave exactly like the process case, we would need to prohibit well-defined, everyday operations. The purpose of consistency is to make things simpler for the user, but there's no good way to replace the lost functionality. And making the process case behave like the persistent case doesn't make sense either; there really are no registers until you start the program. But at the moment, GDB is in kind of a suboptimal state: the distinction is visible, but not exploited where it should be, and there are a few attempts to ignore it that cause annoying behavior. The behavior Daniel's dealing with is an example: if you're talking to a remote target, the 'exec-file' command will currently disconnect you from the target; this is consistent with the native behavior (where we kill the inferior process), but not actually useful to people debugging native targets. I haven't tried to think through yet how to make this concrete --- how commands should behave, and so on. I'm sure doing so would change my understanding.