Patchwork [2/2] Make gdbserver work with filename-only binaries

login
register
mail settings
Submitter Sergio Durigan Junior
Date Feb. 10, 2018, 1:42 a.m.
Message ID <20180210014241.19278-3-sergiodj@redhat.com>
Download mbox | patch
Permalink /patch/25895/
State New
Headers show

Comments

Sergio Durigan Junior - Feb. 10, 2018, 1:42 a.m.
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.

Built and regtested on BuildBot, without regressions.

gdb/ChangeLog:
2018-02-09  Sergio Durigan Junior  <sergiodj@redhat.com>

	* common/common-def.h (current_directory): Move here...
	* defs.h (current_directory): ...from here.

gdb/gdbserver/ChangeLog:
2018-02-09  Sergio Durigan Junior  <sergiodj@redhat.com>

	* server.c: Include "filenames.h" and "pathstuff.h".
	(current_directory): New global variable.
	(adjust_program_name_path): New function.
	(attach_inferior): Call "adjust_program_name_path" before
	"create_inferior".
	(captured_main): Likewise.
	(process_serial_event): Likewise.

gdb/testsuite/ChangeLog:
2018-02-09  Sergio Durigan Junior  <sergiodj@redhat.com>

	* gdb.server/abspath.exp: New file.
	* gdb.server/non-existing-program.exp: Adjust regex for the
	"startup-with-shell enabled" case.
---
 gdb/common/common-defs.h                          |  3 ++
 gdb/defs.h                                        |  4 --
 gdb/gdbserver/server.c                            | 36 +++++++++++++++
 gdb/testsuite/gdb.server/abspath.exp              | 54 +++++++++++++++++++++++
 gdb/testsuite/gdb.server/non-existing-program.exp |  2 +-
 5 files changed, 94 insertions(+), 5 deletions(-)
 create mode 100644 gdb/testsuite/gdb.server/abspath.exp
Simon Marchi - Feb. 12, 2018, 4:18 a.m.
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
Sergio Durigan Junior - Feb. 12, 2018, 7:16 p.m.
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 Durigan Junior - Feb. 12, 2018, 7:57 p.m.
Second version.

These two patches fix the issue pointed by Simon on IRC, that
gdbserver doesn't recognize filename-only binaries anymore:

  $ gdbserver :1234 a.out
  /bin/bash: line 0: exec: a.out: not found
  During startup program exited with code 127.
  Exiting

The first one is a preparation patch (and can go in independently),
which moves path-manipulation functions from utils.c to a new
common/pathstuff.c, making them available for gdbserver as well.

The second patch is the fix itself.

More details in each message.
Joel Brobecker - Feb. 21, 2018, 8:05 a.m.
> 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...

It would, but it would be at the discretion of each target
implementation. linux-low was doing it by calling execv first,
which doesn't search the PATH, and then calling execvp if
the first execv call failed with a "not found" error.

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

I agree with Simon that we shouldn't (and don't really need to) touch
the file when it contains some directory information in it. As far as
I can tell, it already works as is, both with and without shell startup.

    $ gdbserver --once :4444 simple/simple_main
    Process simple/simple_main created; pid = 15400
    Listening on port 4444

    $ gdbserver --no-startup-with-shell --once :4444 simple/simple_main
    Process simple/simple_main created; pid = 15432
    Listening on port 4444

So, I think the only case that we need to worry about is the case
where exec_file is a basename. For that, I think the following test
should be sufficient:

    if (lbasename (exec_file) == exec_file)

... If it returns anything else than exec file, it's either a full
path, or a relative path with some directory information in it.

I agree with you, Sergio, that I think that expanding to the absolute
path would be cleaner. I'm not sure whether adding "." + SLASH_STRING
is going to work everywhere... I'd rather not ask myself the question,
and just expand to a full path, since you've done the work to do it
anyways.

Patch

diff --git a/gdb/common/common-defs.h b/gdb/common/common-defs.h
index acbc32ca69..881a4eaaff 100644
--- a/gdb/common/common-defs.h
+++ b/gdb/common/common-defs.h
@@ -91,4 +91,7 @@ 
 /* Pull in gdb::unique_xmalloc_ptr.  */
 #include "common/gdb_unique_ptr.h"
 
+/* String containing the current directory (what getwd would return).  */
+extern char *current_directory;
+
 #endif /* COMMON_DEFS_H */
diff --git a/gdb/defs.h b/gdb/defs.h
index 4fb2129b30..61be475858 100644
--- a/gdb/defs.h
+++ b/gdb/defs.h
@@ -423,10 +423,6 @@  enum info_proc_what
     IP_ALL
   };
 
-/* * String containing the current directory (what getwd would return).  */
-
-extern char *current_directory;
-
 /* * Default radixes for input and output.  Only some values supported.  */
 extern unsigned input_radix;
 extern unsigned output_radix;
diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
index cb02b58507..2d87886daf 100644
--- a/gdb/gdbserver/server.c
+++ b/gdb/gdbserver/server.c
@@ -39,6 +39,8 @@ 
 #include "common-inferior.h"
 #include "job-control.h"
 #include "environ.h"
+#include "filenames.h"
+#include "pathstuff.h"
 
 #include "common/selftest.h"
 
@@ -56,6 +58,10 @@ 
       break;					\
     }
 
+/* String containing the current directory (what getwd would return).  */
+
+char *current_directory;
+
 /* The environment to pass to the inferior when creating it.  */
 
 static gdb_environ our_environ;
@@ -279,6 +285,23 @@  get_environ ()
   return &our_environ;
 }
 
+/* Verify if PROGRAM_NAME is an absolute path, and perform path
+   adjustment/expansion if not.  */
+
+static void
+adjust_program_name_path ()
+{
+  /* Make sure we're using the absolute path of the inferior when
+     creating it.  */
+  if (!IS_ABSOLUTE_PATH (program_name))
+    {
+      char *tmp_program_name = program_name;
+
+      program_name = gdb_abspath (program_name).release ();
+      xfree (tmp_program_name);
+    }
+}
+
 static int
 attach_inferior (int pid)
 {
@@ -3012,6 +3035,8 @@  handle_v_run (char *own_buf)
       program_name = new_program_name;
     }
 
+  adjust_program_name_path ();
+
   /* Free the old argv and install the new one.  */
   free_vector_argv (program_args);
   program_args = new_argv;
@@ -3539,6 +3564,13 @@  captured_main (int argc, char *argv[])
   const char *selftest_filter = NULL;
 #endif
 
+  current_directory = getcwd (NULL, 0);
+  if (current_directory == NULL)
+    {
+      warning (_("%s: error finding working directory"),
+	       safe_strerror (errno));
+    }
+
   while (*next_arg != NULL && **next_arg == '-')
     {
       if (strcmp (*next_arg, "--version") == 0)
@@ -3759,6 +3791,8 @@  captured_main (int argc, char *argv[])
 	program_args.push_back (xstrdup (next_arg[i]));
       program_args.push_back (NULL);
 
+      adjust_program_name_path ();
+
       /* Wait till we are at first instruction in program.  */
       create_inferior (program_name, program_args);
 
@@ -4279,6 +4313,8 @@  process_serial_event (void)
 	  /* Wait till we are at 1st instruction in prog.  */
 	  if (program_name != NULL)
 	    {
+	      adjust_program_name_path ();
+
 	      create_inferior (program_name, program_args);
 
 	      if (last_status.kind == TARGET_WAITKIND_STOPPED)
diff --git a/gdb/testsuite/gdb.server/abspath.exp b/gdb/testsuite/gdb.server/abspath.exp
new file mode 100644
index 0000000000..fbde5ee537
--- /dev/null
+++ b/gdb/testsuite/gdb.server/abspath.exp
@@ -0,0 +1,54 @@ 
+# This testcase is part of GDB, the GNU debugger.
+
+# Copyright 2018 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Test that gdbserver performs path expansion/adjustment when we
+# provide just a filename (without any path specifications) to it.
+
+load_lib gdbserver-support.exp
+
+standard_testfile normal.c
+
+if { [skip_gdbserver_tests] } {
+    return 0
+}
+
+# We only test things locally, and on native-gdbserver
+if { [is_remote target] || [is_remote host] || ![use_gdb_stub] } {
+    return 0
+}
+
+if { [prepare_for_testing "failed to prepare" $testfile $srcfile debug] } {
+    return -1
+}
+
+set target_exec [gdbserver_download_current_prog]
+set target_execname [file tail $target_exec]
+# We temporarily copy the file to our current directory
+file copy -force $target_exec [pwd]
+set res [gdbserver_start "" $target_execname]
+
+set gdbserver_protocol [lindex $res 0]
+set gdbserver_gdbport [lindex $res 1]
+gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport
+
+if { [runto_main] } {
+    pass "load filename without absolute path"
+} else {
+    fail "load filename without absolute path"
+}
+
+file delete -force "[pwd]/$target_execname"
diff --git a/gdb/testsuite/gdb.server/non-existing-program.exp b/gdb/testsuite/gdb.server/non-existing-program.exp
index a8e057d590..af5b412992 100644
--- a/gdb/testsuite/gdb.server/non-existing-program.exp
+++ b/gdb/testsuite/gdb.server/non-existing-program.exp
@@ -48,7 +48,7 @@  expect {
     }
     # Likewise, but with startup-with-shell enabled, which is the
     # default behaviour.
-    -re "stdin/stdout redirected.*exec: non-existing-program: not found\r\nDuring startup program exited with code 127\.\r\nExiting\r\n$" {
+    -re "stdin/stdout redirected.*: .*non-existing-program: No such file or directory\r\nDuring startup program exited with code 127\.\r\nExiting\r\n$" {
 	set saw_exiting 1
 	exp_continue
     }