kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS
If CONFIG_TRIM_UNUSED_KSYMS is enabled and the kernel is built from
a pristine state, the vmlinux is linked twice.
[1] A user runs 'make'
[2] First build with empty autoksyms.h
[3] adjust_autoksyms.sh updates autoksyms.h and recurses 'make vmlinux'
--------(begin sub-make)--------
[4] Second build with new autoksyms.h
[5] link-vmlinux.sh is invoked because vmlinux is missing
---------(end sub-make)---------
[6] link-vmlinux.sh is invoked again despite vmlinux is up-to-date.
The reason of [6] is probably because Make already decided to update
vmlinux at the time of [2] because vmlinux was missing when Make
built up the dependency graph.
Because if_changed is implemented based on $?, this issue can be
narrowed down to how Make handles $?.
You can test it with the following simple code:
[Test Makefile]
A: B
@echo newer prerequisite: $?
cp B A
B: C
cp C B
touch A
[Result]
$ rm -f A B
$ touch C
$ make
cp C B
touch A
newer prerequisite: B
cp B A
Here, 'A' has been touched in the recipe of 'B'. So, the dependency
'A: B' has already been met before the recipe of 'A' is executed.
However, Make does not notice the fact that the recipe of 'B' also
updates 'A' as a side-effect.
The situation is similar in this case; the vmlinux has actually been
updated in the vmlinux_prereq target. Make cannot predict this, so
judges the vmlinux is old.
link-vmlinux.sh is costly, so it is better to not run it when unneeded.
Split CONFIG_TRIM_UNUSED_KSYMS recursion to a dedicated target.
The reason of commit 2441e78b1919 ("kbuild: better abstract vmlinux
sequential prerequisites") was to cater to CONFIG_BUILD_DOCSRC, but
it was later removed by commit 184892925118 ("samples: move blackfin
gptimers-example from Documentation").
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
1 file changed