From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31844 invoked by alias); 13 Nov 2008 20:33:16 -0000 Received: (qmail 31728 invoked by uid 22791); 13 Nov 2008 20:33:15 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Nov 2008 20:32:37 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mADKWZvh011535; Thu, 13 Nov 2008 15:32:35 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mADKWY0U001514; Thu, 13 Nov 2008 15:32:34 -0500 Received: from opsy.redhat.com (vpn-13-92.rdu.redhat.com [10.11.13.92]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mADKWXsP015462; Thu, 13 Nov 2008 15:32:33 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 7FD4F3786E3; Thu, 13 Nov 2008 13:32:32 -0700 (MST) To: Andreas Schwab Cc: gdb-patches@sourceware.org Subject: Re: RFA: attach to a PID using a different exec References: <20081113192652.GA26537@caradoc.them.org> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Thu, 13 Nov 2008 23:55:00 -0000 In-Reply-To: (Andreas Schwab's message of "Thu\, 13 Nov 2008 21\:05\:28 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00301.txt.bz2 >>>>> "Andreas" == Andreas Schwab writes: Daniel> I don't want GDB to prompt my to switch to the stripped Daniel> program... Andreas> I think a warning would still be helpful, similar to what you Andreas> get when you load a core that does not match. I did consider a warning. My patch was tailored to my use case, where basically I made an early mistake in selecting the exec file. Suppose in this situation that gdb warns about the non-matching exec. After that, gdb is left in an un-useful state, and furthermore the user has to resort to cut-and-paste (or a lot of typing) to get back to the exec file that gdb already knows. That seems unfriendly. I did not think of either Daniel's or Joel's use cases. I would classify Daniel's as advanced usage -- but again, perhaps tinged by my experience. That is, I have never once done what he describes, but then I almost always have separate debug info available for those few stripped programs I must debug. Joel's is an interesting case of making the "opposite" mistake (starting the wrong program), but I think it doesn't really have an effect on the outcome of this discussion (either thing gdb does will yield the right answer when he restarts the inferior and reattaches). Another oddity in this area, btw, is that at least the linux native target gives a funny report if the attached process' exec file has been deleted. I don't like to add new options, in general, but I would add one for this case if that would help. Tom