linux-kernel - Re: Proper use for linking foo.o_shipped after 69ea912fda74 ("kbuild: remove unneeded link_multi

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 6 May 2020 23:37:34 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Michal Marek <michal.lkml@...kovi.net>
Subject: Re: Proper use for linking foo.o_shipped after 69ea912fda74 ("kbuild:
 remove unneeded link_multi_deps")?

On Wed, May 6, 2020 at 1:45 PM Florian Fainelli <f.fainelli@...il.com> wrote:
>
> Hi Masahiro, Michal,
>
> While updating our systems from 4.9 to 5.4, we noticed that one of the
> kernel modules that we build, which is done by linking an object that we
> pre-compile out of Kbuild stopped working.
>
> I bisected it down to:
>
> commit 69ea912fda74a673d330d23595385e5b73e3a2b9 (refs/bisect/bad)
> Author: Masahiro Yamada <yamada.masahiro@...ionext.com>
> Date:   Thu Oct 4 13:25:19 2018 +0900
>
>     kbuild: remove unneeded link_multi_deps
>
>     Since commit c8589d1e9e01 ("kbuild: handle multi-objs dependency
>     appropriately"), $^ really represents all the prerequisite of the
>     composite object being built.
>
>     Hence, $(filter %.o,$^) contains all the objects to link together,
>     which is much simpler than link_multi_deps calculation.
>
>     Please note $(filter-out FORCE,$^) does not work here. When a single
>     object module is turned into a multi object module, $^ will contain
>     header files that were previously included for building the single
>     object, and recorded in the .*.cmd file. To filter out such headers,
>     $(filter %.o,$^) should be used here.
>
>     Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
>
> and the linker now fails with the following:
>
> mkdir -p /home/florian/dev/lkm/.tmp_versions ; rm -f
> /home/florian/dev/lkm/.tmp_versions/*
>
>   WARNING: Symbol version dump ./Module.symvers
>            is missing; modules will have no dependencies and modversions.
>
> make -f ./scripts/Makefile.build obj=/home/florian/dev/lkm
> (cat /dev/null;   echo kernel//home/florian/dev/lkm/hello.ko;) >
> /home/florian/dev/lkm/modules.order
>   ld -m elf_x86_64  -z max-page-size=0x200000    -r -o
> /home/florian/dev/lkm/hello.o
> ld: no input files
> make[1]: *** [scripts/Makefile.build:492: /home/florian/dev/lkm/hello.o]
> Error 1
> make: *** [Makefile:1530: _module_/home/florian/dev/lkm] Error 2
>
> and here are some steps to reproduce this:
>
> Kbuild:
> obj-m   := hello.o
> hello-y := test.o_shipped
>
> test.c can be a simple hello world, and you can compile it using a
> standard Kbuild file first, and then move test.o as test.o_shipped.



Why don't you do like this?

obj-m   := hello.o
hello-y := test.o










> I am afraid I do not speak Kbuild fluently enough to recommend a fix for
> that.
>
> Thanks!
> --
> Florian



-- 
Best Regards
Masahiro Yamada