[v2,2/2] kbuild: link lib-y objects to vmlinux forcibly when CONFIG_MODULES=y
diff mbox series

Message ID 20200311223725.27662-2-masahiroy@kernel.org
State New
Headers show
Series
  • [v2,1/2] sparc: revive __HAVE_ARCH_STRLEN for 32bit sparc
Related show

Commit Message

Masahiro Yamada March 11, 2020, 10:37 p.m. UTC
Kbuild supports not only obj-y but also lib-y to list objects linked to
vmlinux.

The difference between them is that all the objects from obj-y are
forcibly linked to vmlinux by using --whole-archive, whereas the objects
from lib-y are linked as needed; if there is no user of a lib-y object,
it is not linked.

lib-y is intended to list utility functions that may be called from all
over the place (and may be unused at all), but it is a problem for
EXPORT_SYMBOL(). Even if there is no call-site in the vmlinux, we need
to keep exported symbols for the use from loadable modules.

Commit 7f2084fa55e6 ("[kbuild] handle exports in lib-y objects reliably")
worked around it by linking a dummy object, lib-ksyms.o, which contains
references to all the symbols exported from lib.a in that directory.
It uses the linker script command, EXTERN. Unfortunately, the meaning of
EXTERN of ld.lld is different from that of ld.bfd. Therefore, this does
not work with LD=ld.lld (CBL issue #515).

Anyway, the build rule of lib-ksyms.o is somewhat tricky. So, I want to
get rid of it.

At first, I was thinking of accumulating lib-y objects into obj-y
(or even replacing lib-y with obj-y entirely), but the lib-y syntax
is used beyond the ordinary use in lib/ and arch/*/lib/.

Examples:

 - drivers/firmware/efi/libstub/Makefile builds lib.a, which is linked
   into vmlinux in the own way (arm64), or linked to the decompressor
   (arm, x86).

 - arch/alpha/lib/Makefile builds lib.a which is linked not only to
   vmlinux, but also to bootloaders in arch/alpha/boot/Makefile.

 - arch/xtensa/boot/lib/Makefile builds lib.a for use from
   arch/xtensa/boot/boot-redboot/Makefile.

One more thing, adding everything to obj-y would increase the vmlinux
size of allnoconfig (or tinyconfig).

For less impact, I tweaked the destination of lib.a at the top Makefile;
when CONFIG_MODULES=y, lib.a goes to KBUILD_VMLINUX_OBJS, which is
forcibly linked to vmlinux, otherwise lib.a goes to KBUILD_VMLINUX_LIBS
as before.

The size impact for normal usecases is quite small since at lease one
symbol in every lib-y object is eventually called by someone. In case
you are intrested, here are the figures.

x86_64_defconfig:

   text	   data	    bss	    dec	    hex	filename
19566602 5422072 1589328 26578002 1958c52 vmlinux.before
19566932 5422104 1589328 26578364 1958dbc vmlinux.after

The case with the biggest impact is allnoconfig + CONFIG_MODULES=y.

ARCH=x86 allnoconfig + CONFIG_MODULES=y:

   text	   data	    bss	    dec	    hex	filename
1175162	 254740	1220608	2650510	 28718e	vmlinux.before
1177974	 254836	1220608	2653418	 287cea	vmlinux.after

Hopefully this is still not a big deal. The per-file trimming with the
static library is not so effective after all.

If fine-grained optimization is desired, some architectures support
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, which trims dead code per-symbol
basis. When LTO is supported in mainline, even better optimization will
be possible.

Link: https://github.com/ClangBuiltLinux/linux/issues/515
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reported-by: kbuild test robot <lkp@intel.com>
---

Changes in v2: None

 Makefile               |  7 ++++++-
 scripts/Makefile.build | 17 -----------------
 2 files changed, 6 insertions(+), 18 deletions(-)

Comments

kbuild test robot March 12, 2020, 4:30 a.m. UTC | #1
Hi Masahiro,

I love your patch! Yet something to improve:

[auto build test ERROR on kbuild/for-next]
[also build test ERROR on v5.6-rc5 next-20200311]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Masahiro-Yamada/sparc-revive-__HAVE_ARCH_STRLEN-for-32bit-sparc/20200312-073459
base:   https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git for-next
config: mips-cavium_octeon_defconfig (attached as .config)
compiler: mips64-linux-gcc (GCC) 9.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=9.2.0 make.cross ARCH=mips 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   mips64-linux-ld: arch/mips/fw/lib/cmdline.o: in function `fw_init_cmdline':
>> cmdline.c:(.init.text+0x0): multiple definition of `fw_init_cmdline'; arch/mips/cavium-octeon/setup.o:setup.c:(.init.text+0xad8): first defined here
   mips64-linux-ld: arch/mips/lib/delay.o: in function `__delay':
>> delay.c:(.text+0x0): multiple definition of `__delay'; arch/mips/cavium-octeon/csrc-octeon.o:csrc-octeon.c:(.text+0x80): first defined here
   mips64-linux-ld: arch/mips/lib/delay.o: in function `__udelay':
>> delay.c:(.text+0x10): multiple definition of `__udelay'; arch/mips/cavium-octeon/csrc-octeon.o:csrc-octeon.c:(.text+0x8): first defined here
   mips64-linux-ld: arch/mips/lib/delay.o: in function `__ndelay':
>> delay.c:(.text+0x50): multiple definition of `__ndelay'; arch/mips/cavium-octeon/csrc-octeon.o:csrc-octeon.c:(.text+0x40): first defined here
   mips64-linux-ld: arch/mips/lib/memcpy.o: in function `memmove':
>> (.text+0x0): multiple definition of `memmove'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x3a0): first defined here
   mips64-linux-ld: arch/mips/lib/memcpy.o: in function `__rmemcpy':
>> (.text+0x20): multiple definition of `__rmemcpy'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x3c0): first defined here
   mips64-linux-ld: arch/mips/lib/memcpy.o: in function `memcpy':
>> (.text+0x80): multiple definition of `memcpy'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x0): first defined here
   mips64-linux-ld: arch/mips/lib/memcpy.o: in function `memcpy':
>> (.text+0x84): multiple definition of `__copy_user'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x4): first defined here

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
Masahiro Yamada March 12, 2020, 6:12 a.m. UTC | #2
Hi MIPS forks,


I got the following report from 0-day bot.
Please advise me how to fix it.


I am not sure how multi-platform works in MIPS.

The cavium-octeon platform has its own implementation
of various functions.

So, vmlinux links different library routines
depending on whether CONFIG_CAVIUM_OCTEON_SOC, correct?



fw_init_cmdline():
arch/mips/cavium-octeon/setup.c
arch/mips/fw/lib/cmdline.c


__delay(), __udelay(), __ndelay():
arch/mips/cavium-octeon/csrc-octeon.c
arch/mips/lib/delay.S


memcpy(), memmove():
arch/mips/cavium-octeon/octeon-memcpy.S
arch/mips/lib/memcpy.S



FWIW, the following fixes the multiple definition errors.



diff --git a/arch/mips/fw/lib/cmdline.c b/arch/mips/fw/lib/cmdline.c
index 6ecda64ad184..6ac6e0493e1f 100644
--- a/arch/mips/fw/lib/cmdline.c
+++ b/arch/mips/fw/lib/cmdline.c
@@ -16,6 +16,7 @@ int fw_argc;
 int *_fw_argv;
 int *_fw_envp;

+#ifndef CONFIG_CAVIUM_OCTEON_SOC
 void __init fw_init_cmdline(void)
 {
        int i;
@@ -41,6 +42,7 @@ void __init fw_init_cmdline(void)
                        strlcat(arcs_cmdline, " ", COMMAND_LINE_SIZE);
        }
 }
+#endif

 char * __init fw_getcmdline(void)
 {
diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index 479f50559c83..4cc98af4161a 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -3,10 +3,14 @@
 # Makefile for MIPS-specific library files..
 #

-lib-y  += bitops.o csum_partial.o delay.o memcpy.o memset.o \
+lib-y  += bitops.o csum_partial.o memset.o \
           mips-atomic.o strncpy_user.o \
           strnlen_user.o uncached.o

+ifneq ($(CONFIG_CAVIUM_OCTEON_SOC),y)
+lib-y  += delay.o memcpy.o
+endif
+
 obj-y                  += iomap_copy.o
 obj-$(CONFIG_PCI)      += iomap-pci.o
 lib-$(CONFIG_GENERIC_CSUM)     := $(filter-out csum_partial.o, $(lib-y))



On Thu, Mar 12, 2020 at 1:31 PM kbuild test robot <lkp@intel.com> wrote:
>
> Hi Masahiro,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on kbuild/for-next]
> [also build test ERROR on v5.6-rc5 next-20200311]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
>
> url:    https://github.com/0day-ci/linux/commits/Masahiro-Yamada/sparc-revive-__HAVE_ARCH_STRLEN-for-32bit-sparc/20200312-073459
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git for-next
> config: mips-cavium_octeon_defconfig (attached as .config)
> compiler: mips64-linux-gcc (GCC) 9.2.0
> reproduce:
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         GCC_VERSION=9.2.0 make.cross ARCH=mips
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
>    mips64-linux-ld: arch/mips/fw/lib/cmdline.o: in function `fw_init_cmdline':
> >> cmdline.c:(.init.text+0x0): multiple definition of `fw_init_cmdline'; arch/mips/cavium-octeon/setup.o:setup.c:(.init.text+0xad8): first defined here
>    mips64-linux-ld: arch/mips/lib/delay.o: in function `__delay':
> >> delay.c:(.text+0x0): multiple definition of `__delay'; arch/mips/cavium-octeon/csrc-octeon.o:csrc-octeon.c:(.text+0x80): first defined here
>    mips64-linux-ld: arch/mips/lib/delay.o: in function `__udelay':
> >> delay.c:(.text+0x10): multiple definition of `__udelay'; arch/mips/cavium-octeon/csrc-octeon.o:csrc-octeon.c:(.text+0x8): first defined here
>    mips64-linux-ld: arch/mips/lib/delay.o: in function `__ndelay':
> >> delay.c:(.text+0x50): multiple definition of `__ndelay'; arch/mips/cavium-octeon/csrc-octeon.o:csrc-octeon.c:(.text+0x40): first defined here
>    mips64-linux-ld: arch/mips/lib/memcpy.o: in function `memmove':
> >> (.text+0x0): multiple definition of `memmove'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x3a0): first defined here
>    mips64-linux-ld: arch/mips/lib/memcpy.o: in function `__rmemcpy':
> >> (.text+0x20): multiple definition of `__rmemcpy'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x3c0): first defined here
>    mips64-linux-ld: arch/mips/lib/memcpy.o: in function `memcpy':
> >> (.text+0x80): multiple definition of `memcpy'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x0): first defined here
>    mips64-linux-ld: arch/mips/lib/memcpy.o: in function `memcpy':
> >> (.text+0x84): multiple definition of `__copy_user'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x4): first defined here
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org



--
Best Regards
Masahiro Yamada
Thomas Bogendoerfer March 12, 2020, 8:39 a.m. UTC | #3
On Thu, Mar 12, 2020 at 03:12:28PM +0900, Masahiro Yamada wrote:
> I got the following report from 0-day bot.
> Please advise me how to fix it.
> 
> 
> I am not sure how multi-platform works in MIPS.
> 
> The cavium-octeon platform has its own implementation
> of various functions.
> 
> So, vmlinux links different library routines
> depending on whether CONFIG_CAVIUM_OCTEON_SOC, correct?

for cavium memcpy is directly linked in via octeon-memcpy.o, while for
every other platform it's coming from lib/lib.a(memcpy.o).

What have you changed, that this doesn't work anymore ?

Thomas.
Nick Desaulniers March 16, 2020, 11:13 p.m. UTC | #4
On Wed, Mar 11, 2020 at 11:13 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> Hi MIPS forks,
>
>
> I got the following report from 0-day bot.
> Please advise me how to fix it.
>
>
> I am not sure how multi-platform works in MIPS.
>
> The cavium-octeon platform has its own implementation
> of various functions.
>
> So, vmlinux links different library routines
> depending on whether CONFIG_CAVIUM_OCTEON_SOC, correct?
>
>
>
> fw_init_cmdline():
> arch/mips/cavium-octeon/setup.c
> arch/mips/fw/lib/cmdline.c
>
>
> __delay(), __udelay(), __ndelay():
> arch/mips/cavium-octeon/csrc-octeon.c
> arch/mips/lib/delay.S
>
>
> memcpy(), memmove():
> arch/mips/cavium-octeon/octeon-memcpy.S
> arch/mips/lib/memcpy.S
>
>
>
> FWIW, the following fixes the multiple definition errors.
>
>
>
> diff --git a/arch/mips/fw/lib/cmdline.c b/arch/mips/fw/lib/cmdline.c
> index 6ecda64ad184..6ac6e0493e1f 100644
> --- a/arch/mips/fw/lib/cmdline.c
> +++ b/arch/mips/fw/lib/cmdline.c
> @@ -16,6 +16,7 @@ int fw_argc;
>  int *_fw_argv;
>  int *_fw_envp;
>
> +#ifndef CONFIG_CAVIUM_OCTEON_SOC
>  void __init fw_init_cmdline(void)

Alternatively, you could define this fw_init_cmdline as __weak, then
let the strong definition in arch/mips/cavium-octeon/setup.c override
it. But both should work, so:
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Eitherway, octeon has some multiple definition errors that should get fixed.

>  {
>         int i;
> @@ -41,6 +42,7 @@ void __init fw_init_cmdline(void)
>                         strlcat(arcs_cmdline, " ", COMMAND_LINE_SIZE);
>         }
>  }
> +#endif
>
>  char * __init fw_getcmdline(void)
>  {
> diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
> index 479f50559c83..4cc98af4161a 100644
> --- a/arch/mips/lib/Makefile
> +++ b/arch/mips/lib/Makefile
> @@ -3,10 +3,14 @@
>  # Makefile for MIPS-specific library files..
>  #
>
> -lib-y  += bitops.o csum_partial.o delay.o memcpy.o memset.o \
> +lib-y  += bitops.o csum_partial.o memset.o \
>            mips-atomic.o strncpy_user.o \
>            strnlen_user.o uncached.o
>
> +ifneq ($(CONFIG_CAVIUM_OCTEON_SOC),y)
> +lib-y  += delay.o memcpy.o
> +endif
> +
>  obj-y                  += iomap_copy.o
>  obj-$(CONFIG_PCI)      += iomap-pci.o
>  lib-$(CONFIG_GENERIC_CSUM)     := $(filter-out csum_partial.o, $(lib-y))
>
>
>
> On Thu, Mar 12, 2020 at 1:31 PM kbuild test robot <lkp@intel.com> wrote:
> >
> > Hi Masahiro,
> >
> > I love your patch! Yet something to improve:
> >
> > [auto build test ERROR on kbuild/for-next]
> > [also build test ERROR on v5.6-rc5 next-20200311]
> > [if your patch is applied to the wrong git tree, please drop us a note to help
> > improve the system. BTW, we also suggest to use '--base' option to specify the
> > base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
> >
> > url:    https://github.com/0day-ci/linux/commits/Masahiro-Yamada/sparc-revive-__HAVE_ARCH_STRLEN-for-32bit-sparc/20200312-073459
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git for-next
> > config: mips-cavium_octeon_defconfig (attached as .config)
> > compiler: mips64-linux-gcc (GCC) 9.2.0
> > reproduce:
> >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >         chmod +x ~/bin/make.cross
> >         # save the attached .config to linux build tree
> >         GCC_VERSION=9.2.0 make.cross ARCH=mips
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kbuild test robot <lkp@intel.com>
> >
> > All errors (new ones prefixed by >>):
> >
> >    mips64-linux-ld: arch/mips/fw/lib/cmdline.o: in function `fw_init_cmdline':
> > >> cmdline.c:(.init.text+0x0): multiple definition of `fw_init_cmdline'; arch/mips/cavium-octeon/setup.o:setup.c:(.init.text+0xad8): first defined here
> >    mips64-linux-ld: arch/mips/lib/delay.o: in function `__delay':
> > >> delay.c:(.text+0x0): multiple definition of `__delay'; arch/mips/cavium-octeon/csrc-octeon.o:csrc-octeon.c:(.text+0x80): first defined here
> >    mips64-linux-ld: arch/mips/lib/delay.o: in function `__udelay':
> > >> delay.c:(.text+0x10): multiple definition of `__udelay'; arch/mips/cavium-octeon/csrc-octeon.o:csrc-octeon.c:(.text+0x8): first defined here
> >    mips64-linux-ld: arch/mips/lib/delay.o: in function `__ndelay':
> > >> delay.c:(.text+0x50): multiple definition of `__ndelay'; arch/mips/cavium-octeon/csrc-octeon.o:csrc-octeon.c:(.text+0x40): first defined here
> >    mips64-linux-ld: arch/mips/lib/memcpy.o: in function `memmove':
> > >> (.text+0x0): multiple definition of `memmove'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x3a0): first defined here
> >    mips64-linux-ld: arch/mips/lib/memcpy.o: in function `__rmemcpy':
> > >> (.text+0x20): multiple definition of `__rmemcpy'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x3c0): first defined here
> >    mips64-linux-ld: arch/mips/lib/memcpy.o: in function `memcpy':
> > >> (.text+0x80): multiple definition of `memcpy'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x0): first defined here
> >    mips64-linux-ld: arch/mips/lib/memcpy.o: in function `memcpy':
> > >> (.text+0x84): multiple definition of `__copy_user'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x4): first defined here
> >
> > ---
> > 0-DAY CI Kernel Test Service, Intel Corporation
> > https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
>
>
>
> --
> Best Regards
> Masahiro Yamada
Nick Desaulniers March 16, 2020, 11:18 p.m. UTC | #5
+ linux-mips this time

On Mon, Mar 16, 2020 at 4:13 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Wed, Mar 11, 2020 at 11:13 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > Hi MIPS forks,
> >
> >
> > I got the following report from 0-day bot.
> > Please advise me how to fix it.
> >
> >
> > I am not sure how multi-platform works in MIPS.
> >
> > The cavium-octeon platform has its own implementation
> > of various functions.
> >
> > So, vmlinux links different library routines
> > depending on whether CONFIG_CAVIUM_OCTEON_SOC, correct?
> >
> >
> >
> > fw_init_cmdline():
> > arch/mips/cavium-octeon/setup.c
> > arch/mips/fw/lib/cmdline.c
> >
> >
> > __delay(), __udelay(), __ndelay():
> > arch/mips/cavium-octeon/csrc-octeon.c
> > arch/mips/lib/delay.S
> >
> >
> > memcpy(), memmove():
> > arch/mips/cavium-octeon/octeon-memcpy.S
> > arch/mips/lib/memcpy.S
> >
> >
> >
> > FWIW, the following fixes the multiple definition errors.
> >
> >
> >
> > diff --git a/arch/mips/fw/lib/cmdline.c b/arch/mips/fw/lib/cmdline.c
> > index 6ecda64ad184..6ac6e0493e1f 100644
> > --- a/arch/mips/fw/lib/cmdline.c
> > +++ b/arch/mips/fw/lib/cmdline.c
> > @@ -16,6 +16,7 @@ int fw_argc;
> >  int *_fw_argv;
> >  int *_fw_envp;
> >
> > +#ifndef CONFIG_CAVIUM_OCTEON_SOC
> >  void __init fw_init_cmdline(void)
>
> Alternatively, you could define this fw_init_cmdline as __weak, then
> let the strong definition in arch/mips/cavium-octeon/setup.c override
> it. But both should work, so:
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> Eitherway, octeon has some multiple definition errors that should get fixed.
>
> >  {
> >         int i;
> > @@ -41,6 +42,7 @@ void __init fw_init_cmdline(void)
> >                         strlcat(arcs_cmdline, " ", COMMAND_LINE_SIZE);
> >         }
> >  }
> > +#endif
> >
> >  char * __init fw_getcmdline(void)
> >  {
> > diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
> > index 479f50559c83..4cc98af4161a 100644
> > --- a/arch/mips/lib/Makefile
> > +++ b/arch/mips/lib/Makefile
> > @@ -3,10 +3,14 @@
> >  # Makefile for MIPS-specific library files..
> >  #
> >
> > -lib-y  += bitops.o csum_partial.o delay.o memcpy.o memset.o \
> > +lib-y  += bitops.o csum_partial.o memset.o \
> >            mips-atomic.o strncpy_user.o \
> >            strnlen_user.o uncached.o
> >
> > +ifneq ($(CONFIG_CAVIUM_OCTEON_SOC),y)
> > +lib-y  += delay.o memcpy.o
> > +endif
> > +
> >  obj-y                  += iomap_copy.o
> >  obj-$(CONFIG_PCI)      += iomap-pci.o
> >  lib-$(CONFIG_GENERIC_CSUM)     := $(filter-out csum_partial.o, $(lib-y))
> >
> >
> >
> > On Thu, Mar 12, 2020 at 1:31 PM kbuild test robot <lkp@intel.com> wrote:
> > >
> > > Hi Masahiro,
> > >
> > > I love your patch! Yet something to improve:
> > >
> > > [auto build test ERROR on kbuild/for-next]
> > > [also build test ERROR on v5.6-rc5 next-20200311]
> > > [if your patch is applied to the wrong git tree, please drop us a note to help
> > > improve the system. BTW, we also suggest to use '--base' option to specify the
> > > base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
> > >
> > > url:    https://github.com/0day-ci/linux/commits/Masahiro-Yamada/sparc-revive-__HAVE_ARCH_STRLEN-for-32bit-sparc/20200312-073459
> > > base:   https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git for-next
> > > config: mips-cavium_octeon_defconfig (attached as .config)
> > > compiler: mips64-linux-gcc (GCC) 9.2.0
> > > reproduce:
> > >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > >         chmod +x ~/bin/make.cross
> > >         # save the attached .config to linux build tree
> > >         GCC_VERSION=9.2.0 make.cross ARCH=mips
> > >
> > > If you fix the issue, kindly add following tag
> > > Reported-by: kbuild test robot <lkp@intel.com>
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > >    mips64-linux-ld: arch/mips/fw/lib/cmdline.o: in function `fw_init_cmdline':
> > > >> cmdline.c:(.init.text+0x0): multiple definition of `fw_init_cmdline'; arch/mips/cavium-octeon/setup.o:setup.c:(.init.text+0xad8): first defined here
> > >    mips64-linux-ld: arch/mips/lib/delay.o: in function `__delay':
> > > >> delay.c:(.text+0x0): multiple definition of `__delay'; arch/mips/cavium-octeon/csrc-octeon.o:csrc-octeon.c:(.text+0x80): first defined here
> > >    mips64-linux-ld: arch/mips/lib/delay.o: in function `__udelay':
> > > >> delay.c:(.text+0x10): multiple definition of `__udelay'; arch/mips/cavium-octeon/csrc-octeon.o:csrc-octeon.c:(.text+0x8): first defined here
> > >    mips64-linux-ld: arch/mips/lib/delay.o: in function `__ndelay':
> > > >> delay.c:(.text+0x50): multiple definition of `__ndelay'; arch/mips/cavium-octeon/csrc-octeon.o:csrc-octeon.c:(.text+0x40): first defined here
> > >    mips64-linux-ld: arch/mips/lib/memcpy.o: in function `memmove':
> > > >> (.text+0x0): multiple definition of `memmove'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x3a0): first defined here
> > >    mips64-linux-ld: arch/mips/lib/memcpy.o: in function `__rmemcpy':
> > > >> (.text+0x20): multiple definition of `__rmemcpy'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x3c0): first defined here
> > >    mips64-linux-ld: arch/mips/lib/memcpy.o: in function `memcpy':
> > > >> (.text+0x80): multiple definition of `memcpy'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x0): first defined here
> > >    mips64-linux-ld: arch/mips/lib/memcpy.o: in function `memcpy':
> > > >> (.text+0x84): multiple definition of `__copy_user'; arch/mips/cavium-octeon/octeon-memcpy.o:(.text+0x4): first defined here
> > >
> > > ---
> > > 0-DAY CI Kernel Test Service, Intel Corporation
> > > https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
> >
> >
> >
> > --
> > Best Regards
> > Masahiro Yamada
>
>
>
> --
> Thanks,
> ~Nick Desaulniers
Masahiro Yamada March 19, 2020, 3:48 p.m. UTC | #6
Hi Thomas,

On Thu, Mar 12, 2020 at 5:40 PM Thomas Bogendoerfer
<tsbogend@alpha.franken.de> wrote:
>
> On Thu, Mar 12, 2020 at 03:12:28PM +0900, Masahiro Yamada wrote:
> > I got the following report from 0-day bot.
> > Please advise me how to fix it.
> >
> >
> > I am not sure how multi-platform works in MIPS.
> >
> > The cavium-octeon platform has its own implementation
> > of various functions.
> >
> > So, vmlinux links different library routines
> > depending on whether CONFIG_CAVIUM_OCTEON_SOC, correct?
>
> for cavium memcpy is directly linked in via octeon-memcpy.o, while for
> every other platform it's coming from lib/lib.a(memcpy.o).
>
> What have you changed, that this doesn't work anymore ?
>
> Thomas.


I want to change all objects from lib-y
to be linked to vmlinux (exactly like obj-y )
if CONFIG_MODULES is enabled.

https://patchwork.kernel.org/patch/11432969/


EXPORT_SYMBOL in libraries
must be linked to vmlinux all the time,
even if there is no call-site in vmlinux.
I believe this is a good simplification because
EXPORT_SYMBOL is interface to loadable modules.

As it turned out, lib-y is (ab)used to avoid
multiple definition errors.

The 0-day detected a bug of 32-bit sparc:
https://patchwork.kernel.org/patch/11432969/

And, another is this one.

MIPS relies on that
arch/mips/lib/lib.a is weaker than octeon ones.

So, annotating __weak is a good solution
(thanks Nick!).

If I send a patch, is it acceptable?
Thomas Bogendoerfer March 19, 2020, 4:22 p.m. UTC | #7
On Fri, Mar 20, 2020 at 12:48:20AM +0900, Masahiro Yamada wrote:
> Hi Thomas,
> 
> On Thu, Mar 12, 2020 at 5:40 PM Thomas Bogendoerfer
> <tsbogend@alpha.franken.de> wrote:
> >
> > On Thu, Mar 12, 2020 at 03:12:28PM +0900, Masahiro Yamada wrote:
> > > I got the following report from 0-day bot.
> > > Please advise me how to fix it.
> > >
> > >
> > > I am not sure how multi-platform works in MIPS.
> > >
> > > The cavium-octeon platform has its own implementation
> > > of various functions.
> > >
> > > So, vmlinux links different library routines
> > > depending on whether CONFIG_CAVIUM_OCTEON_SOC, correct?
> >
> > for cavium memcpy is directly linked in via octeon-memcpy.o, while for
> > every other platform it's coming from lib/lib.a(memcpy.o).
> >
> > What have you changed, that this doesn't work anymore ?
> >
> > Thomas.
> 
> 
> I want to change all objects from lib-y
> to be linked to vmlinux (exactly like obj-y )
> if CONFIG_MODULES is enabled.

ic

> So, annotating __weak is a good solution
> (thanks Nick!).
> 
> If I send a patch, is it acceptable?

sure.

Thomas.
Masahiro Yamada April 2, 2020, 5:13 p.m. UTC | #8
On Thu, Mar 12, 2020 at 7:38 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> Kbuild supports not only obj-y but also lib-y to list objects linked to
> vmlinux.
>
> The difference between them is that all the objects from obj-y are
> forcibly linked to vmlinux by using --whole-archive, whereas the objects
> from lib-y are linked as needed; if there is no user of a lib-y object,
> it is not linked.
>
> lib-y is intended to list utility functions that may be called from all
> over the place (and may be unused at all), but it is a problem for
> EXPORT_SYMBOL(). Even if there is no call-site in the vmlinux, we need
> to keep exported symbols for the use from loadable modules.
>
> Commit 7f2084fa55e6 ("[kbuild] handle exports in lib-y objects reliably")
> worked around it by linking a dummy object, lib-ksyms.o, which contains
> references to all the symbols exported from lib.a in that directory.
> It uses the linker script command, EXTERN. Unfortunately, the meaning of
> EXTERN of ld.lld is different from that of ld.bfd. Therefore, this does
> not work with LD=ld.lld (CBL issue #515).
>
> Anyway, the build rule of lib-ksyms.o is somewhat tricky. So, I want to
> get rid of it.
>
> At first, I was thinking of accumulating lib-y objects into obj-y
> (or even replacing lib-y with obj-y entirely), but the lib-y syntax
> is used beyond the ordinary use in lib/ and arch/*/lib/.
>
> Examples:
>
>  - drivers/firmware/efi/libstub/Makefile builds lib.a, which is linked
>    into vmlinux in the own way (arm64), or linked to the decompressor
>    (arm, x86).
>
>  - arch/alpha/lib/Makefile builds lib.a which is linked not only to
>    vmlinux, but also to bootloaders in arch/alpha/boot/Makefile.
>
>  - arch/xtensa/boot/lib/Makefile builds lib.a for use from
>    arch/xtensa/boot/boot-redboot/Makefile.
>
> One more thing, adding everything to obj-y would increase the vmlinux
> size of allnoconfig (or tinyconfig).
>
> For less impact, I tweaked the destination of lib.a at the top Makefile;
> when CONFIG_MODULES=y, lib.a goes to KBUILD_VMLINUX_OBJS, which is
> forcibly linked to vmlinux, otherwise lib.a goes to KBUILD_VMLINUX_LIBS
> as before.
>
> The size impact for normal usecases is quite small since at lease one
> symbol in every lib-y object is eventually called by someone. In case
> you are intrested, here are the figures.
>
> x86_64_defconfig:
>
>    text    data     bss     dec     hex filename
> 19566602 5422072 1589328 26578002 1958c52 vmlinux.before
> 19566932 5422104 1589328 26578364 1958dbc vmlinux.after
>
> The case with the biggest impact is allnoconfig + CONFIG_MODULES=y.
>
> ARCH=x86 allnoconfig + CONFIG_MODULES=y:
>
>    text    data     bss     dec     hex filename
> 1175162  254740 1220608 2650510  28718e vmlinux.before
> 1177974  254836 1220608 2653418  287cea vmlinux.after
>
> Hopefully this is still not a big deal. The per-file trimming with the
> static library is not so effective after all.
>
> If fine-grained optimization is desired, some architectures support
> CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, which trims dead code per-symbol
> basis. When LTO is supported in mainline, even better optimization will
> be possible.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/515
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> Reported-by: kbuild test robot <lkp@intel.com>
> ---

Applied to linux-kbuild.

I will rebase my branch during this MW,
so the commit ID will be unstable.
Please do not record it until it lands in Linus' tree.

Patch
diff mbox series

diff --git a/Makefile b/Makefile
index 6a538b79e61e..2cdbd4b3e36d 100644
--- a/Makefile
+++ b/Makefile
@@ -1034,8 +1034,13 @@  init-y		:= $(patsubst %/, %/built-in.a, $(init-y))
 core-y		:= $(patsubst %/, %/built-in.a, $(core-y))
 drivers-y	:= $(patsubst %/, %/built-in.a, $(drivers-y))
 net-y		:= $(patsubst %/, %/built-in.a, $(net-y))
+libs-y2		:= $(patsubst %/, %/built-in.a, $(filter %/, $(libs-y)))
+ifdef CONFIG_MODULES
+libs-y1		:= $(filter-out %/, $(libs-y))
+libs-y2		+= $(patsubst %/, %/lib.a, $(filter %/, $(libs-y)))
+else
 libs-y1		:= $(patsubst %/, %/lib.a, $(libs-y))
-libs-y2		:= $(patsubst %/, %/built-in.a, $(filter-out %.a, $(libs-y)))
+endif
 virt-y		:= $(patsubst %/, %/built-in.a, $(virt-y))
 
 # Externally visible symbols (used by link-vmlinux.sh)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index a1730d42e5f3..356601994f3a 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -65,7 +65,6 @@  endif
 
 ifneq ($(strip $(lib-y) $(lib-m) $(lib-)),)
 lib-target := $(obj)/lib.a
-real-obj-y += $(obj)/lib-ksyms.o
 endif
 
 ifdef need-builtin
@@ -410,22 +409,6 @@  $(lib-target): $(lib-y) FORCE
 
 targets += $(lib-target)
 
-dummy-object = $(obj)/.lib_exports.o
-ksyms-lds = $(dot-target).lds
-
-quiet_cmd_export_list = EXPORTS $@
-cmd_export_list = $(OBJDUMP) -h $< | \
-	sed -ne '/___ksymtab/s/.*+\([^ ]*\).*/EXTERN(\1)/p' >$(ksyms-lds);\
-	rm -f $(dummy-object);\
-	echo | $(CC) $(a_flags) -c -o $(dummy-object) -x assembler -;\
-	$(LD) $(ld_flags) -r -o $@ -T $(ksyms-lds) $(dummy-object);\
-	rm $(dummy-object) $(ksyms-lds)
-
-$(obj)/lib-ksyms.o: $(lib-target) FORCE
-	$(call if_changed,export_list)
-
-targets += $(obj)/lib-ksyms.o
-
 endif
 
 # NOTE: