Re: [PATCH 6/7] Implement qXfer:exec-file:read in gdbserver

[Doug Evans <xdje42 at gmail dot com>]

Gary Benson <gbenson@redhat.com> writes:
> This commit implements the "qXfer:exec-file:read" packet in gdbserver.
>
> gdb/gdbserver/ChangeLog:
>
> 	* target.h (struct target_ops) <pid_to_exec_file>: New field.
> 	* linux-low.c (linux_target_ops): Initialize pid_to_exec_file.
> 	* server.c (handle_qxfer_exec_file): New function.
> 	(qxfer_packets): Add exec-file entry.
> 	(handle_query): Report qXfer:exec-file:read as supported packet.
>
> ...
>
> diff --git a/gdb/gdbserver/target.h b/gdb/gdbserver/target.h
> index 126c861..dc7802d 100644
> --- a/gdb/gdbserver/target.h
> +++ b/gdb/gdbserver/target.h
> @@ -394,6 +394,14 @@ struct target_ops
>  
>    /* Return true if target supports range stepping.  */
>    int (*supports_range_stepping) (void);
> +
> +  /* Return the pathname of the executable file that was run to
> +     create the process PID.  If the executable file cannot be
> +     determined, NULL is returned.  Otherwise, a pointer to a
> +     character string containing the pathname is returned.  This
> +     string should be copied into a buffer by the client if the
> +     string will not be immediately used, or if it must persist.  */
> +  char *(*pid_to_exec_file) (int pid);
>  };
>  
>  extern struct target_ops *the_target;

IWBN to have some clarity on what the pathname result can and cannot be.

Perhaps nitpicky, but the less ambiguity the better.
I think(!) the intent is that the path name is the full
path name, but I could be wrong.

Another issue is whether the path has been real-path'd.
[all symlinks resolved]  I don't have a strong opinion on that,
but I do think we should at least require full paths to be returned here.

const char * result?

Also, I was going to say we need to pick a type for "pid" and consistently
use it, but that's a whole 'nother discussion, and this patch set
needn't be bogged down by it.