lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNARO6HOutPf2VZJMTR2Xmepj_3UiUgH-SLXhH57CNnGfOg@mail.gmail.com>
Date:   Fri, 12 May 2023 03:51:50 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     "Ahmed S. Darwish" <darwi@...utronix.de>
Cc:     Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nicolas Schier <nicolas@...sle.eu>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kbuild@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] scripts/tags.sh: Resolve gtags empty index generation

On Tue, May 9, 2023 at 10:26 AM Ahmed S. Darwish <darwi@...utronix.de> wrote:
>
> gtags considers any file outside of its current working directory
> "outside the source tree" and refuses to index it. For O= kernel builds,
> or when "make" is invoked from a directory other then the kernel source
> tree, gtags ignores the entire kernel source and generates an empty
> index.
>
> Force-set gtags current working directory to the kernel source tree.
>
> Due to commit 9da0763bdd82 ("kbuild: Use relative path when building in
> a subdir of the source tree"), if the kernel build is done in a
> sub-directory of the kernel source tree, the kernel Makefile will set
> the kernel's $srctree to ".." for shorter compile-time and run-time
> warnings. Consequently, the list of files to be indexed will be in the
> "../*" form, rendering all such paths invalid once gtags switches to the
> kernel source tree as its current working directory.
>
> If gtags indexing is requested and the build directory is not the kernel
> source tree, index all files in absolute-path form.
>
> Note, indexing in absolute-path form will not affect the generated
> index, as paths in gtags indices are always relative to the gtags "root
> directory" (as evidenced by "gtags --dump").

The code works as claimed, but I am just curious.
If all the paths are relative, how can you use the tags files located
in a separate directory?

"make O=foo gtags" creates tags files in foo/.
I want to use them from emacs.
emacs cannot find the right file because
it assumes the path is relative to 'foo' instead of the source tree.

I set GTAGSROOT to the source tree, but I could not find a way
to use it in a useful way.



> diff --git a/scripts/tags.sh b/scripts/tags.sh
> index ea31640b2671..3de4b4ebd891 100755
> --- a/scripts/tags.sh
> +++ b/scripts/tags.sh
> @@ -32,6 +32,14 @@ else
>         tree=${srctree}/
>  fi
>
> +

Unneeded empty line addition.


> +# gtags(1) refuses to index any file outside of its current working dir.
> +# If gtags indexing is requested and the build output directory is not
> +# the kernel source tree, index all files in absolute-path form.
> +if [ "$1" = "gtags" -a -n "${tree}" ]; then
> +       tree=$(realpath $tree)/


I decided to run shellcheck for new code.
Please follow the suggestion from the tool.


In scripts/tags.sh line 40:
tree=$(realpath $tree)/
                        ^---^ SC2086 (info): Double quote to prevent
globbing and word splitting.

Did you mean:
tree=$(realpath "$tree")/



(You do not need to fix the entire script.
This is only for new code).



> @@ -131,7 +139,11 @@ docscope()
>
>  dogtags()
>  {
> -       all_target_sources | gtags -i -f -
> +       local gtagsoutdir="${PWD}"
> +       local gtagsroot="${tree}"
> +
> +       [ -z "${gtagsroot}" ] && gtagsroot="."
> +       all_target_sources | gtags -i -C $gtagsroot -f - $gtagsoutdir
>  }


You can write it in one line.


dogtags()
{
    all_target_sources | gtags -i -C "${tree:-.}" -f - "${PWD}"
}





--
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ