[PATCH] kbuild: ignore *.cmd files for objects that come from libgcc.a

[PATCH] kbuild: ignore *.cmd files for objects that come from libgcc.a

[Masahiro Yamada]

Guenter Roeck reported the build breakage for parisc and csky.
I confirmed nios2 and openrisc are broken as well.

The reason is that they borrow libgcc.a from the toolchains.

For example, see this line in arch/parisc/Makefile:

    LIBGCC          := $(shell $(CC) -print-libgcc-file-name)

Some objects in libgcc.a are linked to vmlinux.o, but they do not have
.*.cmd files.

Obviously, there is no EXPORT_SYMBOL in external objects. Ignore them.

(Most of the architectures import library code into the kernel tree.
Perhaps those 4 architectures can do similar, but I am not sure.)

Fixes: f292d875d0dc ("modpost: extract symbol versions from *.cmd files")
Link: https://lore.kernel.org/linux-kbuild/20220528224745.GA2501857@roeck-us.net/T/#mac65c20c71c3e272db0350ecfba53fcd8905b0a0
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---

 scripts/link-vmlinux.sh | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index a7f6196c7e41..68e4be463a76 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -344,9 +344,16 @@ ${MAKE} -f "${srctree}/scripts/Makefile.build" obj=init need-builtin=1
 modpost_link vmlinux.o
 objtool_link vmlinux.o
 
-# Generate the list of objects in vmlinux
+# Generate the list of in-tree objects in vmlinux
+#
+# This is used to retrieve symbol versions generated by genksyms.
 for f in ${KBUILD_VMLINUX_OBJS} ${KBUILD_VMLINUX_LIBS}; do
 	case ${f} in
+	*libgcc.a)
+		# Some architectures do '$(CC) --print-libgcc-file-name' to
+		# borrow libgcc.a from the toolchain.
+		# There is no EXPORT_SYMBOL in external objects. Ignore this.
+		;;
 	*.a)
 		${AR} t ${f} ;;
 	*)
-- 
2.32.0

Re: [PATCH] kbuild: ignore *.cmd files for objects that come from libgcc.a

[Guenter Roeck]

On 5/28/22 21:23, Masahiro Yamada wrote:
> Guenter Roeck reported the build breakage for parisc and csky.
> I confirmed nios2 and openrisc are broken as well.
> 
> The reason is that they borrow libgcc.a from the toolchains.
> 
> For example, see this line in arch/parisc/Makefile:
> 
>      LIBGCC          := $(shell $(CC) -print-libgcc-file-name)
> 
> Some objects in libgcc.a are linked to vmlinux.o, but they do not have
> .*.cmd files.
> 
> Obviously, there is no EXPORT_SYMBOL in external objects. Ignore them.
> 
> (Most of the architectures import library code into the kernel tree.
> Perhaps those 4 architectures can do similar, but I am not sure.)
> 
> Fixes: f292d875d0dc ("modpost: extract symbol versions from *.cmd files")
> Link: https://lore.kernel.org/linux-kbuild/20220528224745.GA2501857@roeck-us.net/T/#mac65c20c71c3e272db0350ecfba53fcd8905b0a0
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Tested-by: Guenter Roeck <linux@roeck-us.net>

> ---
> 
>   scripts/link-vmlinux.sh | 9 ++++++++-
>   1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index a7f6196c7e41..68e4be463a76 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -344,9 +344,16 @@ ${MAKE} -f "${srctree}/scripts/Makefile.build" obj=init need-builtin=1
>   modpost_link vmlinux.o
>   objtool_link vmlinux.o
>   
> -# Generate the list of objects in vmlinux
> +# Generate the list of in-tree objects in vmlinux
> +#
> +# This is used to retrieve symbol versions generated by genksyms.
>   for f in ${KBUILD_VMLINUX_OBJS} ${KBUILD_VMLINUX_LIBS}; do
>   	case ${f} in
> +	*libgcc.a)
> +		# Some architectures do '$(CC) --print-libgcc-file-name' to
> +		# borrow libgcc.a from the toolchain.
> +		# There is no EXPORT_SYMBOL in external objects. Ignore this.
> +		;;
>   	*.a)
>   		${AR} t ${f} ;;
>   	*)

Re: [PATCH] kbuild: ignore *.cmd files for objects that come from libgcc.a

[Stafford Horne]

Cc Joel, Nicolas

On Sun, May 29, 2022 at 01:23:18PM +0900, Masahiro Yamada wrote:
> Guenter Roeck reported the build breakage for parisc and csky.
> I confirmed nios2 and openrisc are broken as well.

Joel reported and issue building the openrisc kernel as well with this error:

    This fails at the link step:

      LD      vmlinux.o
    + or1k-elf-ld -r -o vmlinux.o --whole-archive
    arch/openrisc/kernel/head.o init/built-in.a usr/built-in.a
    arch/openrisc/built-in.a kernel/built-in.a certs/built-in.a
    mm/built-in.a fs/built-in.a ipc/built-in.a security/built-in.a
    crypto/built-in.a block/built-in.a lib/built-in.a drivers/built-in.a
    sound/built-in.a net/built-in.a virt/built-in.a --no-whole-archive
    --start-group lib/lib.a /usr/lib/gcc/or1k-elf/12/libgcc.a --end-group
    or1k-elf-ld: /usr/lib/gcc/or1k-elf/12/libgcc.a: error adding symbols:
    archive has no index; run ranlib to add one

Is it the same? It might be good to have details of the error in the commit
message.

> The reason is that they borrow libgcc.a from the toolchains.
> 
> For example, see this line in arch/parisc/Makefile:
> 
>     LIBGCC          := $(shell $(CC) -print-libgcc-file-name)
> 
> Some objects in libgcc.a are linked to vmlinux.o, but they do not have
> .*.cmd files.
> 
> Obviously, there is no EXPORT_SYMBOL in external objects. Ignore them.
> 
> (Most of the architectures import library code into the kernel tree.
> Perhaps those 4 architectures can do similar, but I am not sure.)

Ill have a look at this.  Could you give an example of what you mean by import
library code, from where?  OpenRISC imports builtins from libgcc, also we have
string and other lib routines from within the port.

-Stafford
 

Re: [PATCH] kbuild: ignore *.cmd files for objects that come from libgcc.a

[Masahiro Yamada]

On Mon, May 30, 2022 at 12:02 AM Stafford Horne <shorne@gmail.com> wrote:
>
> Cc Joel, Nicolas
>
> On Sun, May 29, 2022 at 01:23:18PM +0900, Masahiro Yamada wrote:
> > Guenter Roeck reported the build breakage for parisc and csky.
> > I confirmed nios2 and openrisc are broken as well.
>
> Joel reported and issue building the openrisc kernel as well with this error:
>
>     This fails at the link step:
>
>       LD      vmlinux.o
>     + or1k-elf-ld -r -o vmlinux.o --whole-archive
>     arch/openrisc/kernel/head.o init/built-in.a usr/built-in.a
>     arch/openrisc/built-in.a kernel/built-in.a certs/built-in.a
>     mm/built-in.a fs/built-in.a ipc/built-in.a security/built-in.a
>     crypto/built-in.a block/built-in.a lib/built-in.a drivers/built-in.a
>     sound/built-in.a net/built-in.a virt/built-in.a --no-whole-archive
>     --start-group lib/lib.a /usr/lib/gcc/or1k-elf/12/libgcc.a --end-group
>     or1k-elf-ld: /usr/lib/gcc/or1k-elf/12/libgcc.a: error adding symbols:
>     archive has no index; run ranlib to add one
>
> Is it the same? It might be good to have details of the error in the commit
> message.


Probably, no.

I do not know when the error above happens.



I got the following error message for  ARCH=openrisc allmodconfig.

  CHK     include/generated/compile.h
  UPD     include/generated/compile.h
  CC      init/version.o
  AR      init/built-in.a
  LD      vmlinux.o
  MODPOST vmlinux.symvers
.__mulsi3.o.cmd: No such file or directory
make[2]: *** [scripts/Makefile.modpost:59: vmlinux.symvers] Error 1
make[1]: *** [Makefile:1160: vmlinux] Error 2
make: *** [Makefile:350: __build_one_by_one] Error 2





>
> > The reason is that they borrow libgcc.a from the toolchains.
> >
> > For example, see this line in arch/parisc/Makefile:
> >
> >     LIBGCC          := $(shell $(CC) -print-libgcc-file-name)
> >
> > Some objects in libgcc.a are linked to vmlinux.o, but they do not have
> > .*.cmd files.
> >
> > Obviously, there is no EXPORT_SYMBOL in external objects. Ignore them.
> >
> > (Most of the architectures import library code into the kernel tree.
> > Perhaps those 4 architectures can do similar, but I am not sure.)
>
> Ill have a look at this.  Could you give an example of what you mean by import
> library code, from where?  OpenRISC imports builtins from libgcc, also we have
> string and other lib routines from within the port.
>
> -Stafford
>

"git grep __mulsi3" showed some *.S files of other architectures.

You can ask the authors of the following commits:

4e07dba7cb8c9c76a52d0e32b69f13bb583a9674
dbf4ed894c0fd85d421f7b3b9758ce95398d2925


-- 
Best Regards
Masahiro Yamada