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: Mon, 14 Oct 2013 09:24:09 -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> <52582B57 dot 8090006 at codesourcery dot com> <20131011165622 dot GA20960 at host2 dot jankratochvil dot net> <52583B08 dot 3010907 at codesourcery dot com> <20131011181008 dot GA2115 at host2 dot jankratochvil dot net> <525841CD dot 8070506 at codesourcery dot com> <20131011190020 dot GA13493 at host2 dot jankratochvil dot net>
- Reply-to: lgustavo at codesourcery dot com
On 10/11/2013 04:00 PM, Jan Kratochvil wrote:
On Fri, 11 Oct 2013 20:22:05 +0200, Luis Machado wrote:
Hmmm... unless there is some discrepancy between shell interpreters,
mine (bash) does the following:
OK, true, it works thanks to the 'which' command there.
But then why you have there the conditional
if test "x$binary_path" = x. ; then
?
You can run the 'which' block every time and it will work.
That's true. Though i've noticed that the following gives an unexpected
result...
Invocation: sh gcore (with gcore living in ".")
The /usr/bin/gdb binary gets picked up, because "which gcore" returns
nothing even if gcore lives in ".". *sigh*.
An additional check needs to be done. The attached update patch
accomplishes this. It seems to cover all the scenarios.
I decided to add a chunk of code to error out in case the correct GDB
binary is not found.
Thoughts?
Luis
2013-10-14 Luis Machado <lgustavo@codesourcery.com>
* gcore.in: Call GDB using the full path to the gcore script.
Error out if the GDB binary is not found.
diff --git a/gdb/gcore.in b/gdb/gcore.in
index 9c5b14d..cbc8f06 100644
--- a/gdb/gcore.in
+++ b/gdb/gcore.in
@@ -43,6 +43,40 @@ then
shift; shift
fi
+# 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).
+ binary_basename=`basename "$0"`
+
+ # If the gcore script was called like "sh gcore" and the script
+ # lives in the current directory, "which" will not give us "gcore".
+ # So first we check if the script is in the current directory
+ # before using the output "which".
+ if test -f "$binary_basename" ; then
+ # We have a local gcore script in ".". This covers the case of
+ # doing "./gcore" or "sh gcore".
+ binary_path="."
+ else
+ # The gcore script was not found in ".", which means the script
+ # was called from somewhere else in $PATH. Extract the correct
+ # path now.
+ binary_path_from_env=`which "$0"`
+ binary_path=`dirname "$binary_path_from_env"`
+ fi
+fi
+
+# Check if the GDB binary is in the expected path. If not, just
+# quit with a message.
+if [ ! -f "$binary_path"/@GDB_TRANSFORM_NAME@ ]; then
+ echo "gcore: GDB binary (${binary_path}/@GDB_TRANSFORM_NAME@) not found"
+ exit 1
+fi
+
# Initialise return code.
rc=0
@@ -51,7 +85,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 \
+ $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