From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115450 invoked by alias); 22 Sep 2017 20:37:56 -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 115441 invoked by uid 89); 22 Sep 2017 20:37:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=connects 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; Fri, 22 Sep 2017 20:37:55 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3B7E4552D1; Fri, 22 Sep 2017 20:37:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3B7E4552D1 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 4A39360BE1; Fri, 22 Sep 2017 20:37:50 +0000 (UTC) Subject: Re: [PATCH v3 4/5] Implement "set cwd" command on GDB To: Sergio Durigan Junior , 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> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <9fd4d5eb-0e17-f2e4-97e0-5623c16d82b6@redhat.com> Date: Fri, 22 Sep 2017 20:37: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: <87tvzuzdgv.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-09/txt/msg00699.txt.bz2 On 09/22/2017 09:26 PM, Sergio Durigan Junior wrote: > On Friday, September 22 2017, Eli Zaretskii wrote: > >>> Cc: gdb-patches@sourceware.org >>> From: Pedro Alves >>> Date: Fri, 22 Sep 2017 20:24:40 +0100 >>> >>> (gdb) set cwd ~ # I haven't even connected to a target yet. >>> # Where should this be expanded? >>> # On host may be incorrect. >>> # '~' -> /home/pedro on this machine >> >> You can expand it when you connect. The value has no use until then >> anyway. > > So you're proposing that we discard the previous path expansion done > before connecting, right? I'm just trying to understand your proposal > here, not to bikeshed or anything. > 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) ^^^^^^^^^^^^^ The (^^^) part was meant to indicate "currently expands to this". Which means we'd add a new remote packet to request "expand this path and give me back the result". (I think we could do that as a follow up extension.) 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. Thanks, Pedro Alves