From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29811 invoked by alias); 6 Sep 2017 14:20:57 -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 29765 invoked by uid 89); 6 Sep 2017 14:20:54 -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=Hx-languages-length:5459 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, 06 Sep 2017 14:20:52 +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 9920E81DFA; Wed, 6 Sep 2017 14:20:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9920E81DFA Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.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 A5F2219E71; Wed, 6 Sep 2017 14:20:46 +0000 (UTC) Subject: Re: [PATCH/RFC] Implement the ability to set the current working directory in GDBserver To: Sergio Durigan Junior References: <20170830043811.776-1-sergiodj@redhat.com> <79779c39-8f54-c5da-5450-e67a35294e08@redhat.com> <87shg1yr78.fsf@redhat.com> Cc: GDB Patches , Eli Zaretskii From: Pedro Alves Message-ID: <745cb8c5-f203-e16d-3e36-81005d82a42f@redhat.com> Date: Wed, 06 Sep 2017 14:20: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: <87shg1yr78.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-09/txt/msg00147.txt.bz2 On 09/05/2017 06:45 PM, Sergio Durigan Junior wrote: > On Thursday, August 31 2017, Pedro Alves wrote: > >> On 08/30/2017 06:38 AM, Sergio Durigan Junior wrote: >>> I didn't want to implement a gdbserver-specific command (e.g., "set >>> remote directory"), which means that my approach has some drawbacks. >>> For example, if you want gdbserver to cd to "/abc", but "/abc" doesn't >>> exist in the host, then you still won't be able to do this, because >>> GDB obviously won't allow you to "cd" into a non-existing dir. So you >>> will have to have the same directory structure in both host and target >>> if you want to do that. >> >> I'm not sure this is the right approach. I'd like to have a >> better understanding of what are the use cases "cd" is used for. >> Beyond affecting the inferior's cwd when it is started, what >> else is/can "cd" used for? Or IOW, what else does GDB's >> current working directory affect? > > Good, I was also not 100% this was the right approach either. > > I gave this all a thought yesterday and, before I answer your questions, > I'd like to know if I'm understanding the goal correctly. We want to be > able to instruct gdbserver to change the current working directory > before starting the inferior, correct? I had the impression that this > was the only goal to achieve, but I'm afraid I'm not seeing the entire > picture here. That's part of the goal, yes. However, another goal we should have is to also try to be sure that we end up with a coherent user command line interface. The drawbacks you mention in the proposed commit log look like deal breakers to me, off hand. For native debugging, things were easy -- the inferior always inherits GDB's current working directory. But with remote debugging in the picture, we have a new variable axis -- there's no relation between gdb's filesystem, and the target's. So I worry that trying to fit all use cases through the same UI might not be the best approach. Some use cases are clearly concerned with GDB's current working directory, while other use cases are not. I'd like to pick them apart to be sure to end up with something that makes sense, isn't confusing to users, and doesn't result in awkward uses in some scenarios. > > As for your questions. I looked at the code to find places where the > "current_directory" variable was being used. This is the variable that > ultimately gets changed when "cd" is used. > > Aside from impacting the inferior's cwd, current_directory is also used > on the ".gdb_history" machinery. > > tmpenv = getenv ("GDBHISTFILE"); > if (tmpenv) > history_filename = xstrdup (tmpenv); > else if (!history_filename) > { > /* We include the current directory so that if the user changes > directories the file written will be the same as the one > that was read. */ > #ifdef __MSDOS__ > /* No leading dots in file names are allowed on MSDOS. */ > history_filename = concat (current_directory, "/_gdb_history", > (char *)NULL); > #else > history_filename = concat (current_directory, "/.gdb_history", > (char *)NULL); > #endif > } > read_history (history_filename); > > As John Baldwin also mentioned, 'cd' has an effect when loading GDB > scripts. And probably has an effect when loading other stuff. > > Since gdbserver doesn't really support loading scripts and also doesn't > use .gdb_history, I don't think they are relevant in this case. Well, that's where I disagree -- I think we need to take a step back and look at the wider picture. For example, these settings are per-inferior: (gdb) set environment (gdb) set args E.g.,: (gdb) inferior 1 (gdb) show args "foo" (gdb) inferior 2 (gdb) show args "bar" (gdb) inferior 1 (gdb) show args "foo" This allows preparing multiple independent inferior environments, before starting all inferiors. >From that perspective, the inferior's current working directory looks to me exactly the same kind of variable as "args" or "environment". So from that angle, it'd seem to make sense to make the current working directory that "cd" affects be a per-inferior setting. However, that may conflict with the use cases that expect "cd" to affect where GDB loads scripts from [a host setting], which seems unrelated to the inferior's current working directory [which is a target setting and may resolve to a path in a different machine]. To address that, it'd seem natural to add a "set cwd" command (to go with set args/environment) that would set up a per-inferior current working directory, and leave "cd" for gdb's own current working directory, which affects other things like loading scripts. With that approach, if "show cwd" is empty, then the inferior would inherit gdb's current directory, so it'd end up being a backward compatible extension. Making the setting be per-inferior instead of adding a remote-specific "set remote directory" still addresses local/remote parity, because the interface/feature ends up working the same way independently of native vs remote target. Consider this a strawman proposal, to get the discussion going. I'm not exactly sure it's the best interface either. I also wonder whether "set sysroot" should affect this setting in some way. Maybe. Maybe not. I haven't thought about that. > > Having said that, I'd like to discuss more about the ultimate goal, so > that I know I'm pursuing the right things here. > > Thanks, > Thanks, Pedro Alves