linux-kernel - Re: [PATCH 7/7] kbuild: read *.mod to get objects passed to $(LD) or $(AR)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 7 Apr 2022 12:07:34 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Jeff Johnson <quic_jjohnson@...cinc.com>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH 7/7] kbuild: read *.mod to get objects passed to $(LD) or $(AR)

On Thu, Apr 7, 2022 at 3:13 AM Jeff Johnson <quic_jjohnson@...cinc.com> wrote:
>
> On 4/6/2022 8:30 AM, Masahiro Yamada wrote:
> > ld and ar support @file, which command-line options are read from.
> >
> > Now that *.mod lists the member objects in the correct order, without
> > duplication, it is ready to be passed to ld and ar.
> >
> > By using the @file syntax, people will not be worried about the pitfall
> > described in the NOTE.
> >
> > Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
> > ---
> >
> >   scripts/Makefile.build | 10 +++-------
> >   1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > index 3da731cf6978..f6a506318795 100644
> > --- a/scripts/Makefile.build
> > +++ b/scripts/Makefile.build
> > @@ -450,22 +450,18 @@ quiet_cmd_ar_lib = AR      $@
> >   $(obj)/lib.a: $(lib-y) FORCE
> >       $(call if_changed,ar_lib)
> >
> > -# NOTE:
> > -# Do not replace $(filter %.o,^) with $(real-prereqs). When a single object
> > -# module is turned into a multi object module, $^ will contain header file
> > -# dependencies recorded in the .*.cmd file.
> >   ifneq ($(CONFIG_LTO_CLANG)$(CONFIG_X86_KERNEL_IBT),)
> >   quiet_cmd_link_multi-m = AR [M]  $@
> >   cmd_link_multi-m =                                          \
> >       $(cmd_update_lto_symversions);                          \
> >       rm -f $@;                                               \
> > -     $(AR) cDPrsT $@ $(filter %.o,$^)
> > +     $(AR) cDPrsT $@ @$(patsubst %.o,%.mod,$@)
> >   else
> >   quiet_cmd_link_multi-m = LD [M]  $@
> > -      cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(filter %.o,$^)
> > +      cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ @$(patsubst %.o,%.mod,$@)
> >   endif
> >
> > -$(multi-obj-m): FORCE
> > +$(multi-obj-m): %.o: %.mod FORCE
> >       $(call if_changed,link_multi-m)
> >   $(call multi_depend, $(multi-obj-m), .o, -objs -y -m)
> >
>
> Looks like this also addresses the out-of-tree issue described in
> <https://lore.kernel.org/linux-kbuild/1610500731-30960-2-git-send-email-jjohnson@codeaurora.org/>
>
> :)
>
> /jeff

But, not perfectly.

This patch fixed the linker part, but the same issue is remaining in cmd_mod.

The following patch is an easy fix-up.



diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index f6a506318795..468f9e646370 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -303,8 +303,8 @@ $(obj)/%.prelink.o: $(obj)/%.o FORCE
        $(call if_changed,cc_prelink_modules)
 endif

-cmd_mod = echo $(addprefix $(obj)/, $(call real-search, $*.o, .o,
-objs -y -m)) | \
-       $(AWK) -v RS='( |\n)' '!x[$$0]++' > $@
+cmd_mod = echo $(call real-search, $*.o, .o, -objs -y -m) | \
+       $(AWK) -v RS='( |\n)' '!x[$$0]++ { print("$(obj)/"$$0) }' > $@

 $(obj)/%.mod: FORCE
        $(call if_changed,mod)





But, please do not submit a patch yet.


This patch series is just preparation for yet another
bigger clean-up.

One of my big goals is to clean up Clang LTO builds.

Clang LTO made Kbuild really ugly.

I am re-implementing various parts, but I have not
completed the work yet.

Meanwhile, I incrementally submit prerequisite
refactoring patches.

The issues of external module builds _might_ be fixed
as a side-effect of other refactoring, but I am more
interested in what the final code will look like.

--
Best Regards
Masahiro Yamada