Re: [PATCH/RFC] Implement the ability to set the current working directory in GDBserver

[Pedro Alves <palves at redhat dot com>]

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