From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108126 invoked by alias); 12 May 2015 15:49:09 -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 108111 invoked by uid 89); 12 May 2015 15:49:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-ob0-f172.google.com Received: from mail-ob0-f172.google.com (HELO mail-ob0-f172.google.com) (209.85.214.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 12 May 2015 15:49:07 +0000 Received: by obbkp3 with SMTP id kp3so8776754obb.3 for ; Tue, 12 May 2015 08:49:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bY2EUf8YYAgH892+wMhFObh8Iy6KlHjSPhB2ul29lU0=; b=ehotSPAGXQbhREP7Zac6rOBwS04EqH/W/FLHpG+BVbgJjzRD661P0oU/x93EvGxx2e fyt/AZ/8g3mjx0WRnYK9OYJAaLonAGMPmX/sbzXmRmH2jw+HTOdY85+R5XmxEAjMEBMt Di+NgWkA5TybOSY9qUdu0Fxzcr/7eHToz9o/yP4kJR4ADXnTvgeUAUxMXP5K9cSOoeXE A9YwGAHQiu0usCzTbR2Wu3T2DfA7yIzR+sY1uDfphNI/KN72tlLshvNrSvCWlO9O2dRc 63nyXeIQ5+v69ZNLp+2ZvuC/69aJO+NiEK635Iby7q8N5X/hQj0QionrU5G91CLE7mon X2VA== X-Gm-Message-State: ALoCoQmlvvseRDtK6oXFM84LeAIJioZJuAT/5sbb16FzUM6QQhKZf8N3+EHi9ppMoKIt5BWyDDUB MIME-Version: 1.0 X-Received: by 10.202.84.135 with SMTP id i129mr11711869oib.114.1431445745892; Tue, 12 May 2015 08:49:05 -0700 (PDT) Received: by 10.182.89.99 with HTTP; Tue, 12 May 2015 08:49:05 -0700 (PDT) In-Reply-To: <5551D7AD.8080500@redhat.com> References: <20150505151448.GA1417@blade.nx> <1430907977-30605-1-git-send-email-gbenson@redhat.com> <5551D7AD.8080500@redhat.com> Date: Tue, 12 May 2015 15:49:00 -0000 Message-ID: Subject: Re: [PATCH] Make only user-specified executable filenames sticky From: Doug Evans To: Pedro Alves Cc: Gary Benson , gdb-patches , Philippe Waroquiers Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00276.txt.bz2 On Tue, May 12, 2015 at 3:36 AM, Pedro Alves wrote: > On 05/11/2015 09:23 PM, Doug Evans wrote: >> On Wed, May 6, 2015 at 3:26 AM, Gary Benson wrote: > >>> This commit updates GDB to keep track of which executable filenames >>> were supplied by the user. When GDB might attempt to determine an >>> executable filename and one is already set, filenames determined by >>> GDB may be overridden but user-supplied filenames will not. >> >> I can imagine sometimes wanting either behaviour, depending on >> the situation. > > Yeah, AFAICS, both examples you gave work the same before > and after Gary's patch. > >> E.g., if I supply a file name do some stuff, and then change >> my mind or wish to investigate a difference process I may >> wish gdb to automagically pick up the file name of the new process. > > In that case, one can use "file; attach PID". > > That is, you can just unload the previous program, so that GDB picks > up the new one automatically on next attach. I realize one *could* do that. Thing is, someone's muscle memory may make them expect "attach PID" to Just Work. After all, "bash$ gdb" + "(gdb) attach PID" Just Works. Plus that's two steps. Why do I *have* to first type "file" with no arguments? (Joe User may be thinking) The difference in the two scenarios is explainable, but there's still an incongruity here. We go to lengths to reduce typing in the CLI session. IWBN if one could type, say, "attach -f PID" (f for "force gdb to use the binary of the attached process", or whatever).