Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Sergio Durigan Junior <sergiodj@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org,  palves@redhat.com
Subject: Re: [PATCH/RFC] Implement the ability to set the current working directory in GDBserver
Date: Thu, 31 Aug 2017 21:41:00 -0000	[thread overview]
Message-ID: <8737875sbb.fsf@redhat.com> (raw)
In-Reply-To: <83bmmx2kpq.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 30 Aug	2017 17:28:49 +0300")

On Wednesday, August 30 2017, Eli Zaretskii wrote:

>> From: Sergio Durigan Junior <sergiodj@redhat.com>
>> Cc: Pedro Alves <palves@redhat.com>,
>> 	Eli Zaretskii <eliz@gnu.org>,
>> 	Sergio Durigan Junior <sergiodj@redhat.com>
>> Date: Wed, 30 Aug 2017 00:38:11 -0400
>> 
>> --- a/gdb/NEWS
>> +++ b/gdb/NEWS
>> @@ -17,11 +17,22 @@
>>       "target remote", you can disable the startup with shell by using the
>>       new "--no-startup-with-shell" GDBserver command line option.
>>  
>> +  ** On Unix systems, GDBserver is now able to enter a directory
>> +     before starting an inferior.
>
> Can you tell why this is limited to Unix systems?  The chdir function
> is available much wider than just on Unix.

No particular reason.  This is the same text I've been using in my
latest patches for gdbserver, so I chose to use it again.  I'll rewrite
it to remove this part.

>> +     This is done by using the "cd" command in GDB, which instructs it
>> +     to tell GDBserver about this directory change the next time an
>> +     inferior is run.  If you want to make GDBserver enter the
>> +     directory your GDB is currently in, you can do a "cd ." in GDB.
>
> Couldn't GDB do this "cd ." step under the hood, without bothering
> users with that?

The problem is that we don't really know if the user will want to change
gdbserver's current directory or not.  If we always assume so, this will
lead to many breakages as the directory tree will not be always the same
on host and target.  That's why 'user_set_cwd' is initially false.
However, there's the case when the user may want to change gdbserver's
directory to the same directory GDB is in.  That's why I included this
explanation in the docs.

The more I think about this, the less I'm satisfied with the current
solution.  But I can't really think of a better alternative that doesn't
involve having a separate command to manipulate gdbserver's cwd.

>> +Whenever you specify a new working directory in @value{GDBN}, and if
>> +you are performing a remote debug (@pxref{Remote Debugging}), this
>> +change will be reflected in @command{gdbserver} the next time you run
>> +the program being debugged (@pxref{QSetWorkingDir packet}).  Sometimes
>> +you may want to make @command{gdbserver} enter a directory in which
>> +@value{GDBN} is already in; in this case, you can perform a @code{cd
>> +.} which will not change the current directory in @value{GDBN} but
>> +will force @command{gdbserver} to enter it.
>
> The "@code{cd .}" part should be @kbd{cd .}, and I'd take it in @w{..}
> for a good measure, to prevent it from being broken between 2 lines.

Thanks, fixed.

>> +This packet is only transmitted when the user issues a @code{cd}
>> +command in @value{GDBN} (@xref{Working Directory, ,Your Program's
>> +Working Directory}).
>
> The @xref should be @pxref, as the former is not appropriate in
> parentheses.

Fixed.

> The documentation parts are okay with these nits fixed.

Thanks.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


  reply	other threads:[~2017-08-31 21:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-30  4:38 Sergio Durigan Junior
2017-08-30 14:29 ` Eli Zaretskii
2017-08-31 21:41   ` Sergio Durigan Junior [this message]
2017-09-01 12:32     ` Philippe Waroquiers
2017-09-01 18:40       ` Sergio Durigan Junior
2017-08-31 22:01 ` Pedro Alves
2017-08-31 22:42   ` John Baldwin
2017-09-05 17:45   ` Sergio Durigan Junior
2017-09-06 14:20     ` Pedro Alves
2017-09-06 18:18       ` Sergio Durigan Junior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8737875sbb.fsf@redhat.com \
    --to=sergiodj@redhat.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox