Commit Graph

2 Commits

Author SHA1 Message Date
Mark Wielaard 2b402b25f4 Adjust gdb-add-index.patch to be silent about which gdb
Every invocation of gdb-add-index will print which possible
gdb command will be used. This is because the which command
always prints the name of the command found. Redirect both
stdout and stderr to /dev/null to suppress this when the
output isn't needed.
2023-07-01 18:31:16 +02:00
Andrew Burgess e19c0f8fb7 Rewrite (and rename) gdb-libexec-add-index.patch
It has been observed that the changes added by
gdb-libexec-add-index.patch will result in GDB testing hanging when
the tests are being run using an in-tree GDB; that is when using 'make
check'.  One test that is known to fail is gdb.base/with-mf.exp,
though any test that calls the gdb-add-index.sh script will also hang.

The problem is that when the gdb-add-index.sh script is run, the GDB
testsuite passes the GDB command to use within the GDB environment
variable.  For in-tree testing this will be something like:

  GDB="/path/to/gdb -data-directory /path/to/data-directory"

Notice that the environment variable contains both an executable and
an argument.

Our changes to gdb-add-index.sh add this:

  GDB2=/usr/libexec/gdb
  if test -x $GDB2 && ! which $GDB &>/dev/null; then
      GDB=$GDB2
  fi

The problem then is that '-data-directory' is treated as a set of
options to 'which'.  Many of these options are not known to 'which',
but the '-i' option is known.  The documentation of '-i' says:

    --read-alias, -i
        Read aliases from stdin, reporting matching ones on
        stdout. This is useful in combination with using an alias for
        which itself. For example
        alias which=´alias | which -i´.

And here's the problem; this option causes 'which' to read from
stdin.  As the GDB testsuite doesn't send any additional input on
stdin then the which command will never complete, and the test will
hang.

The solution I think is to avoid calling 'which' like this on a user
supplied GDB environment variable.

The changes in the gdb-libexec-add-index.patch were really about what
the _default_ GDB executable should be.  The upstream version of this
script does this:

  GDB=${GDB:=gdb}

That is, the default is just 'gdb'.  However, for RH this is not good
enough.  We want to handle two additional cases, first, when only the
gdb-minimal package is installed, in which case the default should be
/usr/bin/gdb.minimal.  Then we also want to handle the case where the
user doesn't have 'gdb' itself in their $PATH, but does have the 'gdb'
executable installed in /usr/libexec/gdb.

The code as it currently stands also has a problem where, if
gdb.minimal is installed on the machine this will _always_ be used in
preference to the user supplied GDB value (assuming the code worked at
all) this means that when doing in-tree testing we wouldn't actually
be using the in-tree GDB to build the index, which isn't ideal.

So in this commit I propose that we rework our gdb-add-index.sh
changes.  Now, we only use the RH special values in the case that
there is no GDB environment variable set.  I believe this handles all
the required use cases:

  1. When doing in-tree testing GDB environment variable will be set,
  and this will always be used as is, with no special processing,

  2. When gdb-add-index.sh is used and GDB environment variable is not
  set then we will use the first of the following as the default:

    (a) /usr/bin/gdb.minimal if this file exists and is executable,
    (b) The first gdb executable that can be found in the $PATH,
    (c) /usr/libexec/gdb if this file exists and is executable.

While I was changing this patch anyway I've removed the libexec part
of the patch name -- this no longer seemed relevant, I suspect this
related to an older version of this patch.
2023-05-04 15:11:19 +01:00