From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117801 invoked by alias); 6 Apr 2015 17:11:13 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 117753 invoked by uid 89); 6 Apr 2015 17:11:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f53.google.com Received: from mail-pa0-f53.google.com (HELO mail-pa0-f53.google.com) (209.85.220.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 06 Apr 2015 17:11:11 +0000 Received: by paboj16 with SMTP id oj16so50105888pab.0 for ; Mon, 06 Apr 2015 10:11:09 -0700 (PDT) X-Received: by 10.70.125.162 with SMTP id mr2mr28742775pdb.21.1428340269552; Mon, 06 Apr 2015 10:11:09 -0700 (PDT) Received: from seba.sebabeach.org.gmail.com (173-13-178-53-sfba.hfc.comcastbusiness.net. [173.13.178.53]) by mx.google.com with ESMTPSA id sm3sm5249165pbc.16.2015.04.06.10.11.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Apr 2015 10:11:08 -0700 (PDT) From: Doug Evans To: Gary Benson Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 6/7] Implement qXfer:exec-file:read in gdbserver References: <1427887341-31819-1-git-send-email-gbenson@redhat.com> <1427887341-31819-7-git-send-email-gbenson@redhat.com> Date: Mon, 06 Apr 2015 17:11:00 -0000 In-Reply-To: <1427887341-31819-7-git-send-email-gbenson@redhat.com> (Gary Benson's message of "Wed, 1 Apr 2015 12:22:20 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00153.txt.bz2 Gary Benson writes: > This commit implements the "qXfer:exec-file:read" packet in gdbserver. > > gdb/gdbserver/ChangeLog: > > * target.h (struct target_ops) : 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.