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

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

On Sunday, February 11 2018, Simon Marchi wrote:

> 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,

Hey, Simon,

> 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.

Ah, I guess I didn't consider this (obvious) scenario for gdbserver.  I
was thinking that gdbserver (before the startup-with-shell feature)
would not work with binaries in PATH...

> 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.

Yeah, it crossed my mind to move openp to common, but it's not a trivial
task as you pointed.

> 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

So, what do you think of checking if the file exists in the CWD (and is
executable), and prefixing it with current_directory, as I'm doing with
this patch?  I personally prefer to be more verbose, so using the full
path is better IMHO than just adding "./".

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/