From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29251 invoked by alias); 14 Jun 2006 20:06:44 -0000 Received: (qmail 29241 invoked by uid 22791); 14 Jun 2006 20:06:43 -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 20:06:42 +0000 Received: (qmail 2703 invoked from network); 14 Jun 2006 20:06:40 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Jun 2006 20:06:40 -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 20:06: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/msg00221.txt.bz2 Daniel Jacobowitz writes: > The "file" command currently prompts if a program is running: > > (gdb) file /bin/cat > A program is being debugged already. Kill it? (y or n) > > I've encountered a couple problems with this: > > 1. If you say "no", it aborts the "file" command. So there is no way > to deliberately change the file. > 2. If you say yes, it doesn't just do the equivalent of "kill", but > "kill" and "disconnect". For target extended-remote, this means you > come unexpectedly disconnected from your target. > > This patch completely removes the prompt. Instead, we simply allow it. > It's occasionally useful, even during native debugging (at least I know > I've attached to a running program with the wrong file specified > before). It's more useful during remote debugging, where I've seen > users frequently confused that "target remote; file" doesn't work even > though "file; target remote" does. > > 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 think something like that is workable. What if we simply left the killing to the 'kill' and 'run' commands, and let the prompt say: A program is being debugged already. Are you sure you want to change the file? (y or n) Saying 'y' would not kill the program. This would mean that 'exec-file; run' when a program is running would ask the user two questions: one to confirm the file change, and then another to confirm the kill before restarting.