This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix calling gcore when gdb is not in $PATH.
- From: Luis Machado <lgustavo at codesourcery dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: "'gdb-patches at sourceware dot org'" <gdb-patches at sourceware dot org>
- Date: Fri, 11 Oct 2013 13:46:15 -0300
- Subject: Re: [PATCH] Fix calling gcore when gdb is not in $PATH.
- Authentication-results: sourceware.org; auth=none
- References: <525806C8 dot 8040108 at codesourcery dot com> <20131011143145 dot GA1517 at host2 dot jankratochvil dot net> <52580F4B dot 8050306 at codesourcery dot com>
- Reply-to: lgustavo at codesourcery dot com
On 10/11/2013 11:46 AM, Luis Machado wrote:
On 10/11/2013 11:31 AM, Jan Kratochvil wrote:
On Fri, 11 Oct 2013 16:10:16 +0200, Luis Machado wrote:
--- a/gdb/gcore.in
+++ b/gdb/gcore.in
@@ -51,7 +51,7 @@ for pid in $*
do
# `</dev/null' to avoid touching interactive terminal if it is
# available but not accessible as GDB would get stopped on
SIGTTIN.
- @GDB_TRANSFORM_NAME@ </dev/null --nx --batch \
+ "$(dirname "$0")"/@GDB_TRANSFORM_NAME@ </dev/null --nx --batch \
I have only some concern if $0 does not contain a directory name.
Then `dirname basename` will be . and gdb -> ./gdb will be a
regression as
./gdb will typically not be found.
For example if you run:
$ sh gcore foo
then sh (or bash) executes /usr/bin/gcore but $0 is still just "gcore".
It IMO even corresponds to the sh $0 POSIX description ("command_file"):
http://pubs.opengroup.org/onlinepubs/007908799/xcu/sh.html
Right. That situation can indeed happen. Though it looks a little
awkward to call something in your path like that.
I suppose we can extend the check to cover that case as well. Let me go
back to the drawing board.
Is this one more acceptable (though slightly less portable)?
Regards,
Luis
2013-10-11 Luis Machado <lgustavo@codesourcery.com>
* gcore.in: Call gdb using the full path to the gcore script.
diff --git a/gdb/gcore.in b/gdb/gcore.in
index 9c5b14d..dc6a8f9 100644
--- a/gdb/gcore.in
+++ b/gdb/gcore.in
@@ -49,9 +49,26 @@ rc=0
# Loop through pids
for pid in $*
do
+# Attempt to fetch the absolute path to the gcore script that was
+# called.
+binary_path=`dirname "$0"`
+
+ if test "x$binary_path" = x. ; then
+ # We got "." back as a path. This means the user executed
+ # the gcore script locally (i.e. ./gcore) or called the
+ # script via a shell interpreter (i.e. sh gcore). We use
+ # the "which" command to locate the real path of the gcore
+ # script, disambiguating this situation.
+ binary_path_from_env=`which "$0"`
+ binary_path=`dirname $binary_path_from_env`
+ fi
+
+ # Add a slash to the path.
+ binary_path="$binary_path/"
+
# `</dev/null' to avoid touching interactive terminal if it is
# available but not accessible as GDB would get stopped on SIGTTIN.
- @GDB_TRANSFORM_NAME@ </dev/null --nx --batch \
+ "$binary_path"@GDB_TRANSFORM_NAME@ </dev/null --nx --batch \
-ex "set pagination off" -ex "set height 0" -ex "set width 0" \
-ex "attach $pid" -ex "gcore $name.$pid" -ex detach -ex quit