Re: [PATCH 2/2] Make gdbserver work with filename-only binaries

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2018-02-09 08:42 PM, Sergio Durigan Junior wrote:
> Simon mentioned on IRC that, after the startup-with-shell feature has
> been implemented on gdbserver, it is not possible to specify a
> filename-only binary, like:
> 
>   $ gdbserver :1234 a.out
>   /bin/bash: line 0: exec: a.out: not found
>   During startup program exited with code 127.
>   Exiting
> 
> This happens on systems where the current directory "." is not listed
> in the PATH environment variable.  Although include "." in the PATH
> variable is a possible workaround, this can be considered a regression
> because before startup-with-shell it was possible to use only the
> filename (due to reason that gdbserver used "exec*" directly).
> 
> The idea of the patch is to perform a call to "gdb_abspath" and adjust
> the PROGRAM_NAME variable before the call to "create_inferior".  This
> adjustment will consist of tilde-expansion or prefixing PROGRAM_NAME
> using the CURRENT_DIRECTORY (a variable that was specific to GDB, but
> has been put into common/common-defs.h and now is set/used by
> gdbserver as well), thus transforming PROGRAM_NAME in an absolute
> path.
> 
> This mimicks the behaviour seen on GDB (look at "openp" and
> "attach_inferior", for example).  Now, we'll always execute the binary
> using its full path on gdbserver.
> 
> I am also submitting a testcase which exercises the scenario described
> above.  Because the test requires copying (and deleting) files
> locally, I decided to restrict its execution to non-remote
> targets/hosts.  I've also had to do a minor adjustment on
> gdb.server/non-existing-program.exp's regexp in order to match the
> correct error message.

Hi Sergio,

The behavior is still different than for GDB (and previous gdbservers), in
the case where you specify a filename-only binary that is found in PATH.  For
example, try "gdb ls" and/or "gdbserver ls".  The expected behavior is to
search for a file with this name in the current directory, and if there isn't
one, to search in the PATH.  This is what openp does when OPF_TRY_CWD_FIRST
is passed.

Bringing openp to gdbserver may not be easy nor desirable, since it supports
some concepts that don't exist in gdbserver (like $-variables).  Also, we would
not really want to open the file in this case, only see if it exists.

I didn't think this through completely, but maybe we could do something simpler,
if the program_name doesn't contain a directory separator and the file exists in
the current working directory, we add "./" in front of it when passing it to the
shell?  I think all three use cases would work:

- gdbserver :1234 foo (foo in current directory)
- gdbserver :1234 foo (foo in PATH)
- gdbserver :1234 ./foo

Simon