Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220406153023.500847-1-masahiroy@kernel.org> <20220406153023.500847-8-masahiroy@kernel.org>
 <960102bb-2944-4be0-ab09-7cd2eb0c2cf9@quicinc.com>
In-Reply-To: <960102bb-2944-4be0-ab09-7cd2eb0c2cf9@quicinc.com>
From:   Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu, 7 Apr 2022 12:07:34 +0900
Message-ID: <CAK7LNAStLCBCur3QnfMnBrOUkixYbJK+C6TZVKYcGX9R3M=ANQ@mail.gmail.com>
Subject: Re: [PATCH 7/7] kbuild: read *.mod to get objects passed to $(LD) or $(AR)
To:     Jeff Johnson <quic_jjohnson@quicinc.com>
Cc:     Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Michal Marek <michal.lkml@markovi.net>,
        Nick Desaulniers <ndesaulniers@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Apr 7, 2022 at 3:13 AM Jeff Johnson <quic_jjohnson@quicinc.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@kernel.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