Re: [RFC] "gdbserver ... BASENAME_EXE" no longer works

[Sergio Durigan Junior <sergiodj at redhat dot com>]

On Tuesday, February 20 2018, Joel Brobecker wrote:

> Hello,
>
> I just noticed that the following patch...
>
>     commit 2090129c36c7e582943b7d300968d19b46160d84
>     Date:   Thu Dec 22 21:11:11 2016 -0500
>     Subject: Share fork_inferior et al with gdbserver
>
> ... caused a change of behavior in GDBserver, where the following
> no longer works (unless '.' is in your PATH, but for me, that's
> not a good idea):
>
>     $ gdbserver  --once :4444 simple_main
>     zsh:1: command not found: simple_main
>     During startup program exited with code 127.
>     Exiting
>
> Prior to the change we we able to start simple_main without problems:
>
>     $ gdbserver --once :4444 simple_main
>     Process simple_main created; pid = 26579
>     Listening on port 4444
>
> Was that intentional? Reading the revision log, there is no mention
> of this, and this was a fairly natural thing to be doing. This also
> matches something we do with GDBserver as well, so it would make
> the two tools consistent in that regard.
>
> Attached is a preliminary hack meant to help me explore what would
> be needed to bring this feature back. If we agree we want the feature
> back, and that I'm doing it at the right location, I'll split it,
> finish the C++-ification of the execv_argv class, and then resubmit
> as an official RFA.
>
> Comments on the code welcome, of course! (I feel like a C++ dummy,
> sometimes).

Hi, Joel,

Thanks for the patch.  Just a quick comment since it's past 1a.m. here.
I am trying to tackle this problem from a different angle here:

  https://sourceware.org/ml/gdb-patches/2018-02/msg00178.html

Simon's reply is here:

  https://sourceware.org/ml/gdb-patches/2018-02/msg00181.html

I still have to address it; I intend to do it tomorrow (sorry about the
delay).  I took a different approach than your patch, in that I'm doing
the path expansion before fork_inferior is even called.  The reason for
that is because we already take care of this on GDB by using openp, so I
thought it'd make more sense to modify only gdbserver in this case.

I confess I haven't looked deep into your code, but Simon has mentioned
that he'd like to avoid expanding filename-only paths that contain a
directory component on it.  For example a file name "dir/file" shouldn't
be expanded.

Anyway, I don't know right now if your approach makes more sense than
mine.  I'll give it more thought when I wake up (probably Pedro and/or
Simon will beat me to it).  I'm also planning on submitting v3 of my
current patch, unless the consensus is that your patch is better, of
course.

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/