From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75862 invoked by alias); 29 Sep 2017 15:31:51 -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 75852 invoked by uid 89); 29 Sep 2017 15:31:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=homes, disconnect, expansions X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 29 Sep 2017 15:31:49 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dxxGS-0004Xo-80 for gdb-patches@sourceware.org; Fri, 29 Sep 2017 11:31:47 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxxGS-0004Xf-3r; Fri, 29 Sep 2017 11:31:44 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1304 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dxxGR-0002lr-1B; Fri, 29 Sep 2017 11:31:43 -0400 Date: Fri, 29 Sep 2017 15:31:00 -0000 Message-Id: <83y3ox7c8a.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: sergiodj@redhat.com, gdb-patches@sourceware.org In-reply-to: <93153718-e47d-754b-08b6-60f37cf2ba39@redhat.com> (message from Pedro Alves on Wed, 27 Sep 2017 15:01:58 +0100) Subject: Re: [PATCH v3 4/5] Implement "set cwd" command on GDB Reply-to: Eli Zaretskii References: <20170912042325.14927-1-sergiodj@redhat.com> <20170921225926.23132-1-sergiodj@redhat.com> <20170921225926.23132-5-sergiodj@redhat.com> <83poajcg9a.fsf@gnu.org> <878th64nqk.fsf@redhat.com> <838th6d0l1.fsf@gnu.org> <831smycyia.fsf@gnu.org> <87tvzuzdgv.fsf@redhat.com> <9fd4d5eb-0e17-f2e4-97e0-5623c16d82b6@redhat.com> <83r2uyarha.fsf@gnu.org> <93153718-e47d-754b-08b6-60f37cf2ba39@redhat.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00910.txt.bz2 > Cc: sergiodj@redhat.com, gdb-patches@sourceware.org > From: Pedro Alves > Date: Wed, 27 Sep 2017 15:01:58 +0100 > > Let's say that GDB keeps track of the desired cwd for the inferior > as a single string, like Sergio's patch is doing. Say the user does: > > $ gdb > (gdb) file program > (gdb) set cwd ~ > > At this point, GDB it not "connected" to any target yet. However, > if the user types "run", GDB automatically uses the native > target to run the inferior. So typing "run" after the above is > equivalent to: > > $ gdb > (gdb) file program > (gdb) set cwd ~ > (gdb) target native > (gdb) run > > OK, now the question is, when to expand that '~'. If it is > expanded immediately at "set cwd" time, then we end up expanding > it incorrectly in case the user actually wanted to debug remotely: How about expanding it as part of "target FOO"? > If GDB does not expand the set cwd path ever except internally > when starting the inferior, then the problems shown just above > never happen. But that's an illusory advantage, isn't it? Because we then keep "~", but it expands to something different for every target, and the user has no way of knowing what that will do on another target. Moreover, the user might not even want to have a different expansion for each target. > $ gdb > (gdb) file program > (gdb) set cwd ~ > (gdb) show cwd > cwd is: ~ > expands to /home/pedro on current target > (gdb) start > (gdb) show cwd > cwd is: ~ > expands to /home/pedro on current target > (gdb) kill > (gdb) target extended-remote foo:12345 > (gdb) show cwd > cwd is: ~ > expands to /mnt/home/palves on current target > (gdb) disconnect > (gdb) target extended-remote bar:12345 > (gdb) show cwd > cwd is: ~ > expands to /nfs/homes/pedro on current target > > I'm not sure it's worth the trouble to show the > expansions like this. But if we make GDB _not_ expand > the "set cwd" setting's value itself, as I was proposing, > then we can always come back and improve GDB's output like > above, to inform the user what the setting expands to, > as extra info. Maybe making "show cwd" expand in the right context would be a good middle-ground.