linux-kernel - Re: [PATCH] kbuild: apply fixdep logic to link-vmlinux.sh

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] [day] [month] [year] [list]

Date:   Fri, 5 Mar 2021 23:08:06 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Michal Marek <michal.lkml@...kovi.net>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kbuild: apply fixdep logic to link-vmlinux.sh

On Fri, Mar 5, 2021 at 10:50 PM Masahiro Yamada <masahiroy@...nel.org> wrote:
>
> On Fri, Mar 5, 2021 at 7:02 PM Rasmus Villemoes
> <linux@...musvillemoes.dk> wrote:
> >
> > The patch adding CONFIG_VMLINUX_MAP revealed a small defect in the
> > build system: link-vmlinux.sh takes decisions based on CONFIG_*
> > options, but changing one of those does not always lead to vmlinux
> > being linked again.
> >
> > For most of the CONFIG_* knobs referenced previously, this has
> > probably been hidden by those knobs also affecting some object file,
> > hence indirectly also vmlinux.
> >
> > But CONFIG_VMLINUX_MAP is only handled inside link-vmlinux.sh, and
> > changing CONFIG_VMLINUX_MAP=n to CONFIG_VMLINUX_MAP=y does not cause
> > the build system to re-link (and hence have vmlinux.map
> > emitted). Since that map file is mostly a debugging aid, this is
> > merely a nuisance which is easily worked around by just deleting
> > vmlinux and building again.
> >
> > But one could imagine other (possibly future) CONFIG options that
> > actually do affect the vmlinux binary but which are not captured
> > through some object file dependency.
> >
> > To fix this, make link-vmlinux.sh emit a .vmlinux.d file in the same
> > format as the dependency files generated by gcc, and apply the fixdep
> > logic to that. I've tested that this correctly works with both in-tree
> > and out-of-tree builds.
> >
> > Signed-off-by: Rasmus Villemoes <linux@...musvillemoes.dk>
> > ---
>

I moved the code to the last line of scripts/link-vmlinux.sh,
and added a comment, otherwise, the intent is obscure.



diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 7d4b7c6f01e8..e9516bdfcc6f 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -422,7 +422,6 @@ if [ -n "${CONFIG_KALLSYMS}" ]; then
 fi

 vmlinux_link vmlinux "${kallsymso}" ${btf_vmlinux_bin_o}
-echo "vmlinux: $0" > .vmlinux.d

 # fill in BTF IDs
 if [ -n "${CONFIG_DEBUG_INFO_BTF}" -a -n "${CONFIG_BPF}" ]; then
@@ -451,3 +450,6 @@ if [ -n "${CONFIG_KALLSYMS}" ]; then
                exit 1
        fi
 fi
+
+# For fixdep
+echo "vmlinux: $0" > .vmlinux.d



-- 
Best Regards
Masahiro Yamada