Re: [PATCH v2] [PR gdb/27614] gdb-add-index fails on symlinks.

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2021-03-26 1:11 p.m., Lancelot SIX via Gdb-patches wrote:
> Since V1:
>         - Replace '&>/dev/null' with '>/dev/null 2>&1'
> 
> --
> 
> PR 27614 shows that gdb-add-index fails to generate the index when its
> argument is a symlink.
> 
> The following one liner illustrates the reported problem:
> 
>         $ echo 'int main(){}'|gcc -g -x c -;ln -s a.out symlink;gdb-add-index symlink
>         gdb-add-index: No index was created for symlink
>         gdb-add-index: [Was there no debuginfo? Was there already an index?]
>         $ ls -l
>         -rwxr-xr-x 1 25712 Mar 19 23:05 a.out*
>         -rw------- 1  8277 Mar 19 23:05 a.out.gdb-index
>         lrwxrwxrwx 1     5 Mar 19 23:05 symlink -> a.out*
> 
> GDB generates the .gdb-index file with a name that matches the name of
> the actual program (a.out.gdb-index here), not the symlink that
> references it.  The remaining of the script is looking for a file named
> after the provided argument (would be 'symlink.gdb-index' in our
> example).
> 
> To fix this, this commit proposes to use 'readlink' when available.  This
> command is not part of the standard POSIX tools, so this fix might not
> work in all situations.  It will at least provide an error message to
> the user.
> 
> There are no straightforward solution to go around the problem.  The
> .gdb-index, .debug_names and .debug_str files could be generated and
> then identified by matching *.gdb-index, *.debug_names or *.debug_str.
> This would be problematic if other files where to match this pattern.
> Generating those index files in a dedicated directory raise the problem
> of generating a unique dirname, and mkdtemp is not a standard POSIX
> command so we cannot rely on it either.  It could also be possible to
> use something like "gdb --batch -nx -iex 'set auto-load no' -iex 'file
> $file' -iex 'maint info bfds" and parse its output, but I am not sure
> how future-proof this is.
> 
> Long story short, I went for the simple option that fixes the reported
> issue most of the time instead of trying to come with something
> too complicated for limited added-value.  I can change that if
> required.
> 
> gdb/ChangeLog:
> 
> 	PR gdb/27614
> 	* contrib/gdb-add-index.sh: Fix when called with a symlink as an
> 	argument.
> 
> gdb/testsuite/ChangeLog:
> 
> 	PR gdb/27614
> 	* gdb.dwarf2/gdb-add-index-symlink.exp: New test.
> ---
>  gdb/contrib/gdb-add-index.sh                  | 15 +++++-
>  .../gdb.dwarf2/gdb-add-index-symlink.exp      | 47 +++++++++++++++++++
>  2 files changed, 61 insertions(+), 1 deletion(-)
>  create mode 100644 gdb/testsuite/gdb.dwarf2/gdb-add-index-symlink.exp
> 
> diff --git a/gdb/contrib/gdb-add-index.sh b/gdb/contrib/gdb-add-index.sh
> index 60287b97fba..48a85136a4c 100755
> --- a/gdb/contrib/gdb-add-index.sh
> +++ b/gdb/contrib/gdb-add-index.sh
> @@ -35,7 +35,20 @@ if test $# != 1; then
>      exit 1
>  fi
>  
> -file="$1"
> +if test -L "$1"; then
> +    # This script will most likely fail if the argument is a symlink to a
> +    # program.  In order to avoid that, try to follow the symlink.  However,
> +    # readlink is not a standard POSIX tool so we have to check if it is
> +    # available.
> +    if command -v readlink >/dev/null 2>&1; then
> +	file="$(readlink -e "$1")"

BSDs' readlink doesn't have the -e option, so it would probably derail
from here (should we also check the exit status of readlink to make sure
it worked?  did you try with a symlink pointing to a non-existent file /
with a non-existent component?).

Would it work with just `readlink <file>`?

Simon