diff mbox

[5/7] Implement remote_pid_to_exec_file using qXfer:exec-file:read

Message ID 1427887341-31819-6-git-send-email-gbenson@redhat.com
State Committed
Headers

Commit Message

Gary Benson April 1, 2015, 11:22 a.m. UTC 
  This commit adds a new packet "qXfer:exec-file:read" to the remote
protocol that can be used to obtain the pathname of the file that
was executed to create a process on the remote system.  Support for
this packet is added to GDB and remote_ops.to_pid_to_exec_file is
implemented using it.

gdb/ChangeLog:

	* target.h (TARGET_OBJECT_EXEC_FILE): New enum value.
	* remote.c (PACKET_qXfer_exec_file): Likewise.
	(remote_protocol_features): Register the
	"qXfer:exec-file:read" feature.
	(remote_xfer_partial): Handle TARGET_OBJECT_EXEC_FILE.
	(remote_pid_to_exec_file): New function.
	(init_remote_ops): Initialize to_pid_to_exec_file.
	(_initialize_remote): Register new "set/show remote
	pid-to-exec-file-packet" command.
	* NEWS: Announce new qXfer:exec-file:read packet.

gdb/doc/ChangeLog:

	* gdb.texinfo (Remote Configuration): Document the "set/show
	remote pid-to-exec-file-packet" command.
	(General Query Packets): Document the qXfer:exec-file:read
	qSupported features.  Document the qXfer:exec-file:read packet.
---
 gdb/ChangeLog       |   13 +++++++++++++
 gdb/NEWS            |    4 ++++
 gdb/doc/ChangeLog   |    7 +++++++
 gdb/doc/gdb.texinfo |   22 ++++++++++++++++++++++
 gdb/remote.c        |   35 +++++++++++++++++++++++++++++++++++
 gdb/target.h        |    7 ++++++-
 6 files changed, 87 insertions(+), 1 deletions(-)

Comments

Eli Zaretskii April 1, 2015, 2:54 p.m. UTC | #1 
> From: Gary Benson <gbenson@redhat.com>
> Date: Wed,  1 Apr 2015 12:22:19 +0100
> 
> +qXfer:exec-file:read
> +  Return the pathname of the file that was executed to create a
            ^^^^^^^^^^^^^^^^^^^^^^^^
"the name of the file"

OK with this change.

> +@item qXfer:exec-file:read:@var{annex}:@var{offset},@var{length}
> +@anchor{qXfer executable filename read}
> +Return the pathname of the file that was executed to create a process
          ^^^^^^^^^^^^^^^^^^^^^^^^
Likewise.

Otherwise, the documentation parts are OK.

Thanks.
Doug Evans April 6, 2015, 5 p.m. UTC | #2 
Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed,  1 Apr 2015 12:22:19 +0100
>> 
>> +qXfer:exec-file:read
>> +  Return the pathname of the file that was executed to create a
>             ^^^^^^^^^^^^^^^^^^^^^^^^
> "the name of the file"
>
> OK with this change.
>
>> +@item qXfer:exec-file:read:@var{annex}:@var{offset},@var{length}
>> +@anchor{qXfer executable filename read}
>> +Return the pathname of the file that was executed to create a process
>           ^^^^^^^^^^^^^^^^^^^^^^^^
> Likewise.
>
> Otherwise, the documentation parts are OK.

"the name of the file" is ambiguous though.
Is it the full path name of the file? Or the base name?
Can the target choose? [I hope not.]

IWBN to have more clarity here.

While I realize "path" is a term associated with directories
(paths in which to find files), "full path name" is in common
use for complete/absolute file names.
Eli Zaretskii April 6, 2015, 5:21 p.m. UTC | #3 
> From: Doug Evans <xdje42@gmail.com>
> Cc: Gary Benson <gbenson@redhat.com>,  gdb-patches@sourceware.org
> Date: Mon, 06 Apr 2015 10:00:08 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Wed,  1 Apr 2015 12:22:19 +0100
> >> 
> >> +qXfer:exec-file:read
> >> +  Return the pathname of the file that was executed to create a
> >             ^^^^^^^^^^^^^^^^^^^^^^^^
> > "the name of the file"
> >
> > OK with this change.
> >
> >> +@item qXfer:exec-file:read:@var{annex}:@var{offset},@var{length}
> >> +@anchor{qXfer executable filename read}
> >> +Return the pathname of the file that was executed to create a process
> >           ^^^^^^^^^^^^^^^^^^^^^^^^
> > Likewise.
> >
> > Otherwise, the documentation parts are OK.
> 
> "the name of the file" is ambiguous though.
> Is it the full path name of the file? Or the base name?

I don't know the answers, but if this is a "full path name", then
"the full absolute name of the file" will convey that.

> While I realize "path" is a term associated with directories
> (paths in which to find files), "full path name" is in common
> use for complete/absolute file names.

Yes, we just want to use the latter rather than the former.
Doug Evans April 6, 2015, 9:57 p.m. UTC | #4 
On Mon, Apr 6, 2015 at 10:21 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Doug Evans <xdje42@gmail.com>
>> Cc: Gary Benson <gbenson@redhat.com>,  gdb-patches@sourceware.org
>> Date: Mon, 06 Apr 2015 10:00:08 -0700
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> Date: Wed,  1 Apr 2015 12:22:19 +0100
>> >>
>> >> +qXfer:exec-file:read
>> >> +  Return the pathname of the file that was executed to create a
>> >             ^^^^^^^^^^^^^^^^^^^^^^^^
>> > "the name of the file"
>> >
>> > OK with this change.
>> >
>> >> +@item qXfer:exec-file:read:@var{annex}:@var{offset},@var{length}
>> >> +@anchor{qXfer executable filename read}
>> >> +Return the pathname of the file that was executed to create a process
>> >           ^^^^^^^^^^^^^^^^^^^^^^^^
>> > Likewise.
>> >
>> > Otherwise, the documentation parts are OK.
>>
>> "the name of the file" is ambiguous though.
>> Is it the full path name of the file? Or the base name?
>
> I don't know the answers, but if this is a "full path name", then
> "the full absolute name of the file" will convey that.
>
>> While I realize "path" is a term associated with directories
>> (paths in which to find files), "full path name" is in common
>> use for complete/absolute file names.
>
> Yes, we just want to use the latter rather than the former.

I'm curious why "full path name" is a problem though.
It is such a common term.
Eli Zaretskii April 7, 2015, 6:09 a.m. UTC | #5 
> Date: Mon, 6 Apr 2015 14:57:35 -0700
> From: Doug Evans <xdje42@gmail.com>
> Cc: Gary Benson <gbenson@redhat.com>, 
> 	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> 
> I'm curious why "full path name" is a problem though.

Because the GNU Coding Standards ask us not to use it.
Gary Benson April 7, 2015, 9:08 a.m. UTC | #6 
Eli Zaretskii wrote:
> > From: Doug Evans <xdje42@gmail.com>
> > Cc: Gary Benson <gbenson@redhat.com>,  gdb-patches@sourceware.org
> > Date: Mon, 06 Apr 2015 10:00:08 -0700
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > > Date: Wed,  1 Apr 2015 12:22:19 +0100
> > > > 
> > > > +qXfer:exec-file:read
> > > > +  Return the pathname of the file that was executed to create a
> > >             ^^^^^^^^^^^^^^^^^^^^^^^^
> > > "the name of the file"
> > >
> > > OK with this change.
> > >
> > > > +@item qXfer:exec-file:read:@var{annex}:@var{offset},@var{length}
> > > > +@anchor{qXfer executable filename read}
> > > > +Return the pathname of the file that was executed to create a process
> > >           ^^^^^^^^^^^^^^^^^^^^^^^^
> > > Likewise.
> > >
> > > Otherwise, the documentation parts are OK.
> > 
> > "the name of the file" is ambiguous though.
> > Is it the full path name of the file? Or the base name?
> 
> I don't know the answers, but if this is a "full path name", then
> "the full absolute name of the file" will convey that.

It should be absolute.  I will use "the full absolute name of the
file" as Eli suggests.

Thanks,
Gary
Doug Evans April 8, 2015, 1:57 a.m. UTC | #7 
On Tue, Apr 7, 2015 at 2:08 AM, Gary Benson <gbenson@redhat.com> wrote:
> Eli Zaretskii wrote:
>> > From: Doug Evans <xdje42@gmail.com>
>> > Cc: Gary Benson <gbenson@redhat.com>,  gdb-patches@sourceware.org
>> > Date: Mon, 06 Apr 2015 10:00:08 -0700
>> >
>> > Eli Zaretskii <eliz@gnu.org> writes:
>> >
>> > > > Date: Wed,  1 Apr 2015 12:22:19 +0100
>> > > >
>> > > > +qXfer:exec-file:read
>> > > > +  Return the pathname of the file that was executed to create a
>> > >             ^^^^^^^^^^^^^^^^^^^^^^^^
>> > > "the name of the file"
>> > >
>> > > OK with this change.
>> > >
>> > > > +@item qXfer:exec-file:read:@var{annex}:@var{offset},@var{length}
>> > > > +@anchor{qXfer executable filename read}
>> > > > +Return the pathname of the file that was executed to create a process
>> > >           ^^^^^^^^^^^^^^^^^^^^^^^^
>> > > Likewise.
>> > >
>> > > Otherwise, the documentation parts are OK.
>> >
>> > "the name of the file" is ambiguous though.
>> > Is it the full path name of the file? Or the base name?
>>
>> I don't know the answers, but if this is a "full path name", then
>> "the full absolute name of the file" will convey that.
>
> It should be absolute.  I will use "the full absolute name of the
> file" as Eli suggests.

Is the "full" in "full absolute name" redundant?
Eli Zaretskii April 8, 2015, 6 a.m. UTC | #8 
> Date: Tue, 7 Apr 2015 18:57:39 -0700
> From: Doug Evans <xdje42@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> 
> Is the "full" in "full absolute name" redundant?

To some extent, yes.  But not enough for me to protest.
diff mbox

Patch

diff --git a/gdb/NEWS b/gdb/NEWS
index dec60cb..1486acb 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -90,6 +90,10 @@  hwbreak stop reason
 vFile:fstat:
   Return information about files on the remote system.
 
+qXfer:exec-file:read
+  Return the pathname of the file that was executed to create a
+  process running on the remote system.
+
 * The info record command now shows the recording format and the
   branch tracing configuration for the current thread when using
   the btrace record target.
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 692d70e..3c4e47a 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -19677,6 +19677,10 @@  are:
 @tab @code{Z4}
 @tab @code{awatch}
 
+@item @code{pid-to-exec-file}
+@tab @code{qXfer:exec-file:read}
+@tab @code{attach}, @code{run}
+
 @item @code{target-features}
 @tab @code{qXfer:features:read}
 @tab @code{set architecture}
@@ -35900,6 +35904,11 @@  These are the currently defined stub features and their properties:
 @tab @samp{-}
 @tab Yes
 
+@item @samp{qXfer:exec-file:read}
+@tab No
+@tab @samp{-}
+@tab Yes
+
 @item @samp{qXfer:features:read}
 @tab No
 @tab @samp{-}
@@ -36103,6 +36112,10 @@  packet (@pxref{qXfer btrace read}).
 The remote stub understands the @samp{qXfer:btrace-conf:read}
 packet (@pxref{qXfer btrace-conf read}).
 
+@item qXfer:exec-file:read
+The remote stub understands the @samp{qXfer:exec-file:read} packet
+(@pxref{qXfer executable filename read}).
+
 @item qXfer:features:read
 The remote stub understands the @samp{qXfer:features:read} packet
 (@pxref{qXfer target description read}).
@@ -36417,6 +36430,15 @@  Return a description of the current branch trace configuration.
 This packet is not probed by default; the remote stub must request it
 by supplying an appropriate @samp{qSupported} response (@pxref{qSupported}).
 
+@item qXfer:exec-file:read:@var{annex}:@var{offset},@var{length}
+@anchor{qXfer executable filename read}
+Return the pathname of the file that was executed to create a process
+running on the remote system.  The annex specifies the numeric process
+ID of the process to query, encoded as a hexadecimal number.
+
+This packet is not probed by default; the remote stub must request it,
+by supplying an appropriate @samp{qSupported} response (@pxref{qSupported}).
+
 @item qXfer:features:read:@var{annex}:@var{offset},@var{length}
 @anchor{qXfer target description read}
 Access the @dfn{target description}.  @xref{Target Descriptions}.  The
diff --git a/gdb/remote.c b/gdb/remote.c
index 69a67a8..a307e68 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -1252,6 +1252,7 @@  enum {
   PACKET_vFile_fstat,
   PACKET_qXfer_auxv,
   PACKET_qXfer_features,
+  PACKET_qXfer_exec_file,
   PACKET_qXfer_libraries,
   PACKET_qXfer_libraries_svr4,
   PACKET_qXfer_memory_map,
@@ -3963,6 +3964,8 @@  static const struct protocol_feature remote_protocol_features[] = {
   { "PacketSize", PACKET_DISABLE, remote_packet_size, -1 },
   { "qXfer:auxv:read", PACKET_DISABLE, remote_supported_packet,
     PACKET_qXfer_auxv },
+  { "qXfer:exec-file:read", PACKET_DISABLE, remote_supported_packet,
+    PACKET_qXfer_exec_file },
   { "qXfer:features:read", PACKET_DISABLE, remote_supported_packet,
     PACKET_qXfer_features },
   { "qXfer:libraries:read", PACKET_DISABLE, remote_supported_packet,
@@ -9035,6 +9038,11 @@  remote_xfer_partial (struct target_ops *ops, enum target_object object,
 				len, xfered_len,
 	&remote_protocol_packets[PACKET_qXfer_btrace_conf]);
 
+    case TARGET_OBJECT_EXEC_FILE:
+      return remote_read_qxfer (ops, "exec-file", annex, readbuf, offset,
+				len, xfered_len,
+	&remote_protocol_packets[PACKET_qXfer_exec_file]);
+
     default:
       return TARGET_XFER_E_IO;
     }
@@ -11642,6 +11650,29 @@  remote_load (struct target_ops *self, const char *name, int from_tty)
   generic_load (name, from_tty);
 }
 
+/* Accepts an integer PID; returns a string representing a file that
+   can be opened on the remote side to get the symbols for the child
+   process.  Returns NULL if the operation is not supported.  */
+
+static char *
+remote_pid_to_exec_file (struct target_ops *self, int pid)
+{
+  static char *filename = NULL;
+  char annex[9];
+
+  if (packet_support (PACKET_qXfer_exec_file) != PACKET_ENABLE)
+    return NULL;
+
+  if (filename != NULL)
+    xfree (filename);
+
+  xsnprintf (annex, sizeof (annex), "%x", pid);
+  filename = target_read_stralloc (&current_target,
+				   TARGET_OBJECT_EXEC_FILE, annex);
+
+  return filename;
+}
+
 static void
 init_remote_ops (void)
 {
@@ -11691,6 +11722,7 @@  Specify the serial device it is connected to\n\
   remote_ops.to_stop = remote_stop;
   remote_ops.to_xfer_partial = remote_xfer_partial;
   remote_ops.to_rcmd = remote_rcmd;
+  remote_ops.to_pid_to_exec_file = remote_pid_to_exec_file;
   remote_ops.to_log_command = serial_log_command;
   remote_ops.to_get_thread_local_address = remote_get_thread_local_address;
   remote_ops.to_stratum = process_stratum;
@@ -12219,6 +12251,9 @@  Show the maximum size of the address (in bits) in a memory packet."), NULL,
   add_packet_config_cmd (&remote_protocol_packets[PACKET_qXfer_auxv],
 			 "qXfer:auxv:read", "read-aux-vector", 0);
 
+  add_packet_config_cmd (&remote_protocol_packets[PACKET_qXfer_exec_file],
+			 "qXfer:exec-file:read", "pid-to-exec-file", 0);
+
   add_packet_config_cmd (&remote_protocol_packets[PACKET_qXfer_features],
 			 "qXfer:features:read", "target-features", 0);
 
diff --git a/gdb/target.h b/gdb/target.h
index 01ec5f5..693379a 100644
--- a/gdb/target.h
+++ b/gdb/target.h
@@ -204,7 +204,12 @@  enum target_object
   /* Branch trace data, in XML format.  */
   TARGET_OBJECT_BTRACE,
   /* Branch trace configuration, in XML format.  */
-  TARGET_OBJECT_BTRACE_CONF
+  TARGET_OBJECT_BTRACE_CONF,
+  /* The pathname of the executable file that was run to create
+     a specified process.  ANNEX should be a string representation
+     of the process ID of the process in question, in hexadecimal
+     format.  */
+  TARGET_OBJECT_EXEC_FILE,
   /* Possible future objects: TARGET_OBJECT_FILE, ...  */
 };