On Fri, Aug 25, 2023 at 5:06 PM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
>
> On Sat, Aug 26, 2023 at 6:45 AM Nick Desaulniers
> <ndesaulniers@xxxxxxxxxx> wrote:
> >
> > On Thu, Aug 24, 2023 at 11:59 AM Nathan Chancellor <nathan@xxxxxxxxxx> wrote:
> > >
> > > On Wed, Aug 23, 2023 at 01:20:42PM -0700, Nathan Chancellor wrote:
> > > > Hi Masahiro,
> > > >
> > > > On Wed, Aug 23, 2023 at 09:08:16PM +0900, Masahiro Yamada wrote:
> > > > > Revert the following two commits:
> > > > >
> > > > > - 7273ad2b08f8 ("kbuild: link lib-y objects to vmlinux forcibly when CONFIG_MODULES=y")
> > > > > - 7f2084fa55e6 ("[kbuild] handle exports in lib-y objects reliably")
> > > > >
> > > > > Now, lib-y is back to static library again, and the link order is
> > > > > consistent w/wo CONFIG_MODULES.
> > > > >
> > > > > Since commit ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by
> > > > > modpost"), .vmlinux.export.c contains references to exported symbols.
> > > > > If a symbol in a lib-y object is exported, that object is always linked
> > > > > even without any explicit user in vmlinux.
> > > > >
> > > > > Signed-off-by: Masahiro Yamada <masahiroy@xxxxxxxxxx>
> > > > > ---
> > > > >
> > > > > Makefile | 5 -----
> > > > > 1 file changed, 5 deletions(-)
> > > > >
> > > > > diff --git a/Makefile b/Makefile
> > > > > index 87a9eef3fb4b..71e9c65d9eae 100644
> > > > > --- a/Makefile
> > > > > +++ b/Makefile
> > > > > @@ -1113,12 +1113,7 @@ export ARCH_DRIVERS := $(drivers-y) $(drivers-m)
> > > > > # Externally visible symbols (used by link-vmlinux.sh)
> > > > >
> > > > > KBUILD_VMLINUX_OBJS := ./built-in.a
> > > > > -ifdef CONFIG_MODULES
> > > > > -KBUILD_VMLINUX_OBJS += $(patsubst %/, %/lib.a, $(filter %/, $(libs-y)))
> > > > > -KBUILD_VMLINUX_LIBS := $(filter-out %/, $(libs-y))
> > > > > -else
> > > > > KBUILD_VMLINUX_LIBS := $(patsubst %/,%/lib.a, $(libs-y))
> > > > > -endif
> > > > >
> > > > > export KBUILD_VMLINUX_LIBS
> > > > > export KBUILD_LDS := arch/$(SRCARCH)/kernel/vmlinux.lds
> > > > > --
> > > > > 2.39.2
> > > > >
> > > >
> > > > The build error that prompted 7273ad2b08f8 from [1] appears to return
> > > > with this patch, for example:
> > > >
> > > > $ make -skj"$(nproc)" ARCH=arm64 LLVM=1 O=build mrproper virtconfig all
> > > > ...
> > > > ERROR: modpost: "__memcat_p" [drivers/hwtracing/stm/stm_core.ko] undefined!
> > > > ...
> > > >
> > > > [1]: https://github.com/ClangBuiltLinux/linux/issues/515
> > >
> > > One thing I forgot to note with this is this occurs when targeting arm,
> > > arm64, hexagon, i386, powerpc, s390, and x86_64 with various in-tree
> > > configurations (I can provide a list if necessary).
> >
> > shot in the dark here, but does this help? (Nathan indicates it does,
> > at least for `ARCH=arm64 virtconfig`)
> > ```
> > diff --git a/lib/Makefile b/lib/Makefile
> > index 1ffae65bb7ee..289ab15f8659 100644
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@ -33,9 +33,11 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
> > flex_proportions.o ratelimit.o \
> > is_single_threaded.o plist.o decompress.o kobject_uevent.o \
> > earlycpio.o seq_buf.o siphash.o dec_and_lock.o \
> > - nmi_backtrace.o win_minmax.o memcat_p.o \
> > + nmi_backtrace.o win_minmax.o \
> > buildid.o
> >
> > +obj-y += memcat_p.o
> > +
>
>
> No. it is not a solution.
>
> We will end up with a whack-a-mole game
> because this kind of issue (EXPORT_SYMBOL from lib-y)
> happens in general.
>
>
>
>
>
>
> > lib-$(CONFIG_PRINTK) += dump_stack.o
> > lib-$(CONFIG_SMP) += cpumask.o
> >
> > ```
> > Masahiro,
> > I don't fully understand "when to use obj-y vs lib-y" in a kernel
> > Makefile. I've read Documentation/kbuild/makefiles.rst and I still
> > don't get it. Is this answered elsewhere in the docs? Can you explain
> > it to me? Do we need to update the docs?
>
>
> The original intention (that existed before I became the Kbuild maintainer) was:
>
> obj-y linked to vmlinux unconditionally
>
> lib-y : the compiled object goes into a static library. Hence,
> conditionally linked.
> (If no symbol in lib-y object is referenced, it is not linked at all)
>
>
>
>
>
> If ARCH supports CONFIG_LD_DEAD_CODE_DATA_ELIMINATION,
> it is more optimal.
>
>
> With lib-y, objects are conditionally linked.
Then wrt. memcat_p, it sounds like there should be a Kconfig for that
that drivers such as drivers/hwtracing/stm/stm_core.ko can express a
dependency on. Yeah?
>
> With CONFIG_LD_DEAD_CODE_DATA_ELIMINATION,
> symbols are conditionally linked.
>
>
>
>
>
> One solution could be to delete lib-y entirely.
>
>
> --
> Best Regards
> Masahiro Yamada
--
Thanks,
~Nick Desaulniers
