From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2010 invoked by alias); 13 Nov 2008 20:09:48 -0000 Received: (qmail 1959 invoked by uid 22791); 13 Nov 2008 20:09:47 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Nov 2008 20:09:10 +0000 Received: (qmail 23396 invoked from network); 13 Nov 2008 20:09:09 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 13 Nov 2008 20:09:09 -0000 Message-ID: <491C895F.7030500@codesourcery.com> Date: Thu, 13 Nov 2008 23:24:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Tom Tromey CC: gdb-patches@sourceware.org Subject: Re: RFA: attach to a PID using a different exec References: <20081113192652.GA26537@caradoc.them.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00299.txt.bz2 Tom Tromey wrote: >>>>>> "Daniel" == Daniel Jacobowitz writes: >>>>>> >>> This patch changes gdb to look at the target's notion of the exec >>> file, and then switch to it if it differs from the current exec. >>> > > Daniel> This seems like a bad idea to me. The canonical example is: > Daniel> /usr/bin/prog.stripped & > Daniel> gdb /home/drow/prog.debug $(pidof prog.stripped) > Daniel> I don't want GDB to prompt my to switch to the stripped program... > > Well, you can answer "no". So while it is inconvenient, it seems > minor. On the other hand, the current situation can leave one with a > nonsensical setup. This bites me a lot more than I should probably > admit. > For multi-exec GDB, I added a set-exec command for just this situation - if you have multiple execs in the session, it's extremely difficult to tell which (if any) corresponds to the attached process. In practice so far, it's better than nothing, but we need more. We should have as many heuristics as possible, and ask for a confirmation too. (I wonder if comparing a handful of bytes, or sections, from each exec would be a useful check...) Stan