From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110285 invoked by alias); 13 Sep 2017 15:00:00 -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 110276 invoked by uid 89); 13 Sep 2017 14:59:59 -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= 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, 13 Sep 2017 14:59:58 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0ACD4356CC; Wed, 13 Sep 2017 14:59:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0ACD4356CC Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.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 A425960C43; Wed, 13 Sep 2017 14:59:53 +0000 (UTC) Subject: Re: [PATCH 0/4] New "set cwd" command To: Sergio Durigan Junior , Eli Zaretskii References: <20170912042325.14927-1-sergiodj@redhat.com> <83fubsq84f.fsf@gnu.org> <87zi9zeud6.fsf@redhat.com> <83o9qfq2i1.fsf@gnu.org> <87poaverfb.fsf@redhat.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <5ffa3c27-6659-280d-922d-8d0fe6db470f@redhat.com> Date: Wed, 13 Sep 2017 15:00: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: <87poaverfb.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-09/txt/msg00359.txt.bz2 On 09/12/2017 06:51 PM, Sergio Durigan Junior wrote: > On Tuesday, September 12 2017, Eli Zaretskii wrote: > >>> From: Sergio Durigan Junior >>> Cc: gdb-patches@sourceware.org, palves@redhat.com >>> Date: Tue, 12 Sep 2017 12:48:05 -0400 >>> >>> The new "set cwd" command also uses chdir (i.e., no shell involved), but >>> because it is shared code between GDB and gdbserver, and because >>> gdbserver doesn't link against readline, it cannot use tilde_expand. >>> Therefore I had to import the "glob" module from gnulib. And also, this >>> specific chdir is only invoked after the call to fork/vfork on >>> fork_inferior, but before we actually execute the binary. >> >> Thanks. >> >> The last bit means that this will only work for targets that use >> fork/vfork, i.e. only for Posix targets. Right? > > Well, the way it's implemented, yes. AFAIK there's nothing preventing > this feature to be implemented in non-vfork targets like Windows, except > the fact that I don't have access to those targets to test. I think that to make "set cwd" work on Windows, gdb would be adjusted to pass the desired current directory as argument to CreateProcess, here: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/windows-nat.c;h=ab5582d46cf3a0873ab32d9c955e95ee75371d4e;hb=HEAD#l2570 (and the equivalent in gdbserver). >From : ~~~ lpCurrentDirectory [in, optional] The full path to the current directory for the process. The string can also specify a UNC path. If this parameter is NULL, the new process will have the same current drive and directory as the calling process. (This feature is provided primarily for shells that need to start an application and specify its initial drive and working directory.) ~~~ Thanks, Pedro Alves