From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128381 invoked by alias); 27 Sep 2017 14:02:17 -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 128366 invoked by uid 89); 27 Sep 2017 14:02:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=disconnect, homes, nowhere, palves 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 ESMTP; Wed, 27 Sep 2017 14:02:07 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F3366FF4C; Wed, 27 Sep 2017 14:02:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F3366FF4C Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves@redhat.com Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 83E2280608; Wed, 27 Sep 2017 14:01:59 +0000 (UTC) Subject: Re: [PATCH v3 4/5] Implement "set cwd" command on GDB 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> Cc: sergiodj@redhat.com, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <93153718-e47d-754b-08b6-60f37cf2ba39@redhat.com> Date: Wed, 27 Sep 2017 14:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <83r2uyarha.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-09/txt/msg00825.txt.bz2 On 09/23/2017 06:55 AM, Eli Zaretskii wrote: >> Cc: gdb-patches@sourceware.org >> From: Pedro Alves >> Date: Fri, 22 Sep 2017 21:37:49 +0100 >> >> That would mean keep both non-expanded, and expanded paths around, >> which is what I was suggesting with: >> >> (gdb) set cwd ~foo/bar >> (gdb) show cwd >> The current directory is ~foo/bar (/home/foo/bar) >> ^^^^^^^^^^^^^ > > Keeping both is also OK, although I don't see how it would solve the > problems Pedro mentioned earlier, and also now: > >> But that's not what I understood Eli suggesting. I understood >> it as gdb expanding whatever's the value set on connection. >> But I don't see how that could work, because before gdb connects >> to a remote target explicitly, it's as if gdb was connected to >> the native target (that's how "run" works without typing >> "target native" explicitly, though you can type that), so >> by the time you connect to the remote target, it's already >> too late, gdb has already expanded on the host, and there's >> nothing left to expand. > > I don't understand this description, which is not surprising, since my > knowledge of the machinery involved in this is very superficial. > 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: $ gdb (gdb) file program (gdb) set cwd ~ (gdb) show cwd /home/pedro # local path, doesn't exists on the 'foo' machine. (gdb) target extended-remote foo:12345 (gdb) show cwd /home/pedro # does not exist on 'foo' If is it instead expanded only when GDB connects to a target, then we get this: $ gdb (gdb) file program (gdb) set cwd ~ (gdb) show cwd ~ # not expanded yet! (gdb) start # gdb expands ~ -> /home/pedro, then starts the inferior (gdb) show cwd /home/pedro # now it's expanded. users scratches head. (gdb) kill (gdb) target extended-remote foo:12345 # switch same inferior # to different target (gdb) show cwd /home/pedro # whoops, lost original '~' path, and this path # doesn't make sense for the 'foo' machine. If GDB does not expand the set cwd path ever except internally when starting the inferior, then the problems shown just above never happen. > Keeping both is also OK, although I don't see how it would solve the > problems Pedro mentioned earlier, and also now: The problems I mentioned are solved by not expanding in the first place. Saving both original-path-as-specified-by-user and expanded-path (or expanding on demand when displaying the path to the user and saving it nowhere) would then be a way to let the user know what the path expands to on the current target, without losing the originally set path. Like: $ 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. Hope that is clearer. Thanks, Pedro Alves