From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65981 invoked by alias); 13 May 2015 09:12:37 -0000 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 Received: (qmail 65969 invoked by uid 89); 13 May 2015 09:12:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 13 May 2015 09:12:36 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4D9CVij010248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 13 May 2015 05:12:31 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4D9CTcu025047; Wed, 13 May 2015 05:12:30 -0400 Message-ID: <5553157D.3060104@redhat.com> Date: Wed, 13 May 2015 09:12:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gary Benson , Doug Evans CC: gdb-patches , Philippe Waroquiers Subject: Re: [PATCH] Make only user-specified executable filenames sticky References: <20150505151448.GA1417@blade.nx> <1430907977-30605-1-git-send-email-gbenson@redhat.com> <5551D7AD.8080500@redhat.com> <20150513075456.GA3730@blade.nx> In-Reply-To: <20150513075456.GA3730@blade.nx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg00299.txt.bz2 On 05/13/2015 08:54 AM, Gary Benson wrote: > I asked already, but nobody answered, so... I did reply :-) Here: https://sourceware.org/ml/gdb-patches/2015-05/msg00273.html > > If you say "attach PID", and GDB can see that PID's executable is > /foo/bar, and the current exec-file is not /foo/bar/, under what > circumstances should GDB *not* automatically reload the new exec- > file? For the symbol-file part, it's clear: we need the debug info that might well be missing on the running copy of the binary (I know that's not what you're asking). When the running image does not have all the info we need out of the executable (in which case you'll have passed a non-stripped binary to gdb). I pointed out section info, as that's what I thought of off hand. There may be other bits needed. Grepping around for exec_bfd may find more. Of course, determining whether the file has the necessary bits requires downloading/opening the file, which is something the user may want to avoid. > i.e. why could this "attach -f" behavior not be the default? If we come up with means to force usage of the current exec, maybe. Though maybe we're trying to make gdb too smart, as in, some obscure cases things may go wrong, depending on program/binary and target you connect to, which is confusing. The "user-specified==sticky" idea seems simpler to explain to users to me. If GDB warned on exec-file vs running image mismatch, I think the default would matter less. Thanks, Pedro Alves