Hi all,
Today's linux-next merge of the tip tree got a conflict in:
scripts/Makefile.build
between commit:
0212301af7bb ("kbuild: do not create *.prelink.o for Clang LTO or IBT")
from the kbuild tree and commit:
753da4179d08 ("objtool: Remove --lto and --vmlinux in favor of --link")
from the tip tree.
I am not sure if I fixed this up correctly, please check the final result
when linux-next is released.
I fixed it up (I used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
Hi all,
On Mon, 23 May 2022 14:24:31 +1000 Stephen Rothwell <[email protected]> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> scripts/Makefile.build
>
> between commit:
>
> 0212301af7bb ("kbuild: do not create *.prelink.o for Clang LTO or IBT")
>
> from the kbuild tree and commit:
>
> 753da4179d08 ("objtool: Remove --lto and --vmlinux in favor of --link")
>
> from the tip tree.
>
> I am not sure if I fixed this up correctly, please check the final result
> when linux-next is released.
>
> I fixed it up (I used the former version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
That produced may warnings :-( so I tried the below resolution instead.
--
Cheers,
Stephen Rothwell
70023a983b831421d2bac71f46b94bce024a147b
diff --cc scripts/Makefile.build
index 48712bfc8740,f89d3fcff39f..cbe9b45e7b7d
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@@ -226,18 -244,23 +230,19 @@@ objtool_args =
cmd_objtool = $(if $(objtool-enabled), ; $(objtool) $(objtool_args) $@)
cmd_gen_objtooldep = $(if $(objtool-enabled), { echo ; echo '$@: $$(wildcard $(objtool))' ; } >> $(dot-target).cmd)
- endif # CONFIG_STACK_VALIDATION
+ endif # CONFIG_OBJTOOL
-ifneq ($(CONFIG_LTO_CLANG)$(CONFIG_X86_KERNEL_IBT),)
-
-# Skip objtool for LLVM bitcode
-$(obj)/%.o: objtool-enabled :=
-
-else
# 'OBJECT_FILES_NON_STANDARD := y': skip objtool checking for a directory
# 'OBJECT_FILES_NON_STANDARD_foo.o := 'y': skip objtool checking for a file
# 'OBJECT_FILES_NON_STANDARD_foo.o := 'n': override directory skip for a file
-$(obj)/%.o: objtool-enabled = $(if $(filter-out y%, \
- $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n),y)
+is-standard-object = $(if $(filter-out y%, $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n),y)
-endif
+delay-objtool := $(or $(CONFIG_LTO_CLANG),$(CONFIG_X86_KERNEL_IBT))
+
+$(obj)/%.o: objtool-enabled = $(if $(is-standard-object),$(if $(delay-objtool),$(is-single-obj-m),y))
++$(obj)/%.o: linked-object := y
ifdef CONFIG_TRIM_UNUSED_KSYMS
cmd_gen_ksymdeps = \
@@@ -404,24 -464,32 +409,25 @@@ $(obj)/modules.order: $(obj-m) FORC
#
# Rule to compile a set of .o files into one .a file (with symbol table)
#
-quiet_cmd_ar_lib = AR $@
- cmd_ar_lib = $(cmd_update_lto_symversions); $(cmd_ar)
$(obj)/lib.a: $(lib-y) FORCE
- $(call if_changed,ar_lib)
-
-# NOTE:
-# Do not replace $(filter %.o,^) with $(real-prereqs). When a single object
-# module is turned into a multi object module, $^ will contain header file
-# dependencies recorded in the .*.cmd file.
-ifneq ($(CONFIG_LTO_CLANG)$(CONFIG_X86_KERNEL_IBT),)
-quiet_cmd_link_multi-m = AR [M] $@
-cmd_link_multi-m = \
- $(cmd_update_lto_symversions); \
- rm -f $@; \
- $(AR) cDPrsT $@ $(filter %.o,$^)
-else
-quiet_cmd_link_multi-m = LD [M] $@
- cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(filter %.o,$^)
-endif
+ $(call if_changed,ar)
+
+quiet_cmd_ld_multi_m = LD [M] $@
+ cmd_ld_multi_m = $(LD) $(ld_flags) -r -o $@ @$(patsubst %.o,%.mod,$@) $(cmd_objtool)
+
+define rule_ld_multi_m
+ $(call cmd_and_savecmd,ld_multi_m)
+ $(call cmd,gen_objtooldep)
+endef
-$(multi-obj-m): FORCE
- $(call if_changed,link_multi-m)
+$(multi-obj-m): objtool-enabled := $(delay-objtool)
+$(multi-obj-m): part-of-module := y
++$(multi-obj-m): linked-object := y
+$(multi-obj-m): %.o: %.mod FORCE
+ $(call if_changed_rule,ld_multi_m)
$(call multi_depend, $(multi-obj-m), .o, -objs -y -m)
-targets += $(multi-obj-m)
targets := $(filter-out $(PHONY), $(targets))
# Add intermediate targets:
On Mon, May 23, 2022 at 03:47:58PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 23 May 2022 14:24:31 +1000 Stephen Rothwell <[email protected]> wrote:
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > scripts/Makefile.build
> >
> > between commit:
> >
> > 0212301af7bb ("kbuild: do not create *.prelink.o for Clang LTO or IBT")
> >
> > from the kbuild tree and commit:
> >
> > 753da4179d08 ("objtool: Remove --lto and --vmlinux in favor of --link")
> >
> > from the tip tree.
> >
> > I am not sure if I fixed this up correctly, please check the final result
> > when linux-next is released.
> >
> > I fixed it up (I used the former version) and can carry the fix as
> > necessary. This is now fixed as far as linux-next is concerned, but any
> > non trivial conflicts should be mentioned to your upstream maintainer
> > when your tree is submitted for merging. You may also want to consider
> > cooperating with the maintainer of the conflicting tree to minimise any
> > particularly complex conflicts.
>
> That produced may warnings :-( so I tried the below resolution instead.
Looks good to me. I guess the confusing bit was that in most cases,
CONFIG_STACK_VALIDATION has been replaced with CONFIG_OBJTOOL.
--
Josh
On Fri, May 27, 2022 at 1:47 PM Josh Poimboeuf <[email protected]> wrote:
>
> On Fri, May 27, 2022 at 11:19:02AM +0900, Masahiro Yamada wrote:
> > [1] original behavior in Josh's commit
> >
> > $ git checkout 753da4179d08b625d8df72e97724e22749969fd3
> > $ make defconfig
> > $ make -j8 kernel/
> > $ head -n 1 kernel/.fork.o.cmd
> >
> >
> > I do not see the "--linked" parameter in the objtool command.
> >
> >
> >
> >
> > [2] behavior in linux-next
> >
> >
> > $ git checkout next-20220523
> > $ make defconfig
> > $ make -j8 kernel/
> > $ head -n 1 kernel/.fork.o.cmd
> >
> > I see the "--linked" parameter in the objtool command.
> >
> > kernel/fork.o is a direct output from GCC,
> > not from linker.
>
> Yes, good catch. That flag should only be used for linked objects like
> vmlinux.o or some_module.o.
>
> Objtool only runs on such objects when CONFIG_LTO_CLANG,
> CONFIG_X86_KERNEL_IBT, or CONFIG_NOINSTR_VALIDATION (vmlinux.o-only) is
> enabled.
>
> --
> Josh
When CONFIG_LTO_CLANG=y or CONFIG_X86_KERNEL_IBT=y
is "--linked" necessary for single-object modules?
"single-object module" means a module that consists of only one object.
See this figure:
https://patchwork.kernel.org/project/linux-kbuild/patch/[email protected]/
In your commit, --linked is passed to all *.prelink.o
whether it consists of a single object or links
multiple objects.
--
Best Regards
Masahiro Yamada
On Fri, May 27, 2022 at 11:19:02AM +0900, Masahiro Yamada wrote:
> [1] original behavior in Josh's commit
>
> $ git checkout 753da4179d08b625d8df72e97724e22749969fd3
> $ make defconfig
> $ make -j8 kernel/
> $ head -n 1 kernel/.fork.o.cmd
>
>
> I do not see the "--linked" parameter in the objtool command.
>
>
>
>
> [2] behavior in linux-next
>
>
> $ git checkout next-20220523
> $ make defconfig
> $ make -j8 kernel/
> $ head -n 1 kernel/.fork.o.cmd
>
> I see the "--linked" parameter in the objtool command.
>
> kernel/fork.o is a direct output from GCC,
> not from linker.
Yes, good catch. That flag should only be used for linked objects like
vmlinux.o or some_module.o.
Objtool only runs on such objects when CONFIG_LTO_CLANG,
CONFIG_X86_KERNEL_IBT, or CONFIG_NOINSTR_VALIDATION (vmlinux.o-only) is
enabled.
--
Josh
On Fri, May 27, 2022 at 3:04 PM Masahiro Yamada <[email protected]> wrote:
>
> On Fri, May 27, 2022 at 1:47 PM Josh Poimboeuf <[email protected]> wrote:
> >
> > On Fri, May 27, 2022 at 11:19:02AM +0900, Masahiro Yamada wrote:
> > > [1] original behavior in Josh's commit
> > >
> > > $ git checkout 753da4179d08b625d8df72e97724e22749969fd3
> > > $ make defconfig
> > > $ make -j8 kernel/
> > > $ head -n 1 kernel/.fork.o.cmd
> > >
> > >
> > > I do not see the "--linked" parameter in the objtool command.
> > >
> > >
> > >
> > >
> > > [2] behavior in linux-next
> > >
> > >
> > > $ git checkout next-20220523
> > > $ make defconfig
> > > $ make -j8 kernel/
> > > $ head -n 1 kernel/.fork.o.cmd
> > >
> > > I see the "--linked" parameter in the objtool command.
> > >
> > > kernel/fork.o is a direct output from GCC,
> > > not from linker.
> >
> > Yes, good catch. That flag should only be used for linked objects like
> > vmlinux.o or some_module.o.
> >
> > Objtool only runs on such objects when CONFIG_LTO_CLANG,
> > CONFIG_X86_KERNEL_IBT, or CONFIG_NOINSTR_VALIDATION (vmlinux.o-only) is
> > enabled.
> >
> > --
> > Josh
>
>
> When CONFIG_LTO_CLANG=y or CONFIG_X86_KERNEL_IBT=y
> is "--linked" necessary for single-object modules?
>
>
> "single-object module" means a module that consists of only one object.
>
> See this figure:
> https://patchwork.kernel.org/project/linux-kbuild/patch/[email protected]/
>
>
>
>
> In your commit, --linked is passed to all *.prelink.o
> whether it consists of a single object or links
> multiple objects.
Anyway, please let me clean up this part in the kbuild tree:
https://patchwork.kernel.org/project/linux-kbuild/patch/[email protected]/
--
Best Regards
Masahiro Yamada
On Fri, May 27, 2022 at 03:04:57PM +0900, Masahiro Yamada wrote:
> On Fri, May 27, 2022 at 1:47 PM Josh Poimboeuf <[email protected]> wrote:
> >
> > On Fri, May 27, 2022 at 11:19:02AM +0900, Masahiro Yamada wrote:
> > > [1] original behavior in Josh's commit
> > >
> > > $ git checkout 753da4179d08b625d8df72e97724e22749969fd3
> > > $ make defconfig
> > > $ make -j8 kernel/
> > > $ head -n 1 kernel/.fork.o.cmd
> > >
> > >
> > > I do not see the "--linked" parameter in the objtool command.
> > >
> > >
> > >
> > >
> > > [2] behavior in linux-next
> > >
> > >
> > > $ git checkout next-20220523
> > > $ make defconfig
> > > $ make -j8 kernel/
> > > $ head -n 1 kernel/.fork.o.cmd
> > >
> > > I see the "--linked" parameter in the objtool command.
> > >
> > > kernel/fork.o is a direct output from GCC,
> > > not from linker.
> >
> > Yes, good catch. That flag should only be used for linked objects like
> > vmlinux.o or some_module.o.
> >
> > Objtool only runs on such objects when CONFIG_LTO_CLANG,
> > CONFIG_X86_KERNEL_IBT, or CONFIG_NOINSTR_VALIDATION (vmlinux.o-only) is
> > enabled.
> >
> > --
> > Josh
>
>
> When CONFIG_LTO_CLANG=y or CONFIG_X86_KERNEL_IBT=y
> is "--linked" necessary for single-object modules?
Yes.
> "single-object module" means a module that consists of only one object.
>
> See this figure:
> https://patchwork.kernel.org/project/linux-kbuild/patch/[email protected]/
Nice patch description!
> In your commit, --linked is passed to all *.prelink.o
> whether it consists of a single object or links
> multiple objects.
Yes, we want to keep that behavior. Thanks!
--
Josh
Hi Stephen, Josh,
On Tue, May 24, 2022 at 1:23 AM Josh Poimboeuf <[email protected]> wrote:
>
> On Mon, May 23, 2022 at 03:47:58PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > On Mon, 23 May 2022 14:24:31 +1000 Stephen Rothwell <[email protected]> wrote:
> > >
> > > Today's linux-next merge of the tip tree got a conflict in:
> > >
> > > scripts/Makefile.build
> > >
> > > between commit:
> > >
> > > 0212301af7bb ("kbuild: do not create *.prelink.o for Clang LTO or IBT")
> > >
> > > from the kbuild tree and commit:
> > >
> > > 753da4179d08 ("objtool: Remove --lto and --vmlinux in favor of --link")
> > >
> > > from the tip tree.
> > >
> > > I am not sure if I fixed this up correctly, please check the final result
> > > when linux-next is released.
> > >
> > > I fixed it up (I used the former version) and can carry the fix as
> > > necessary. This is now fixed as far as linux-next is concerned, but any
> > > non trivial conflicts should be mentioned to your upstream maintainer
> > > when your tree is submitted for merging. You may also want to consider
> > > cooperating with the maintainer of the conflicting tree to minimise any
> > > particularly complex conflicts.
> >
> > That produced may warnings :-( so I tried the below resolution instead.
>
> Looks good to me. I guess the confusing bit was that in most cases,
> CONFIG_STACK_VALIDATION has been replaced with CONFIG_OBJTOOL.
>
> --
> Josh
Is this really a correct fix up?
I checked the linux-next.
It added:
$(obj)/%.o: linked-object := y
so, --linked is always passed.
Apparently, it changed the behavior.
[1] original behavior in Josh's commit
$ git checkout 753da4179d08b625d8df72e97724e22749969fd3
$ make defconfig
$ make -j8 kernel/
$ head -n 1 kernel/.fork.o.cmd
I do not see the "--linked" parameter in the objtool command.
[2] behavior in linux-next
$ git checkout next-20220523
$ make defconfig
$ make -j8 kernel/
$ head -n 1 kernel/.fork.o.cmd
I see the "--linked" parameter in the objtool command.
kernel/fork.o is a direct output from GCC,
not from linker.
Josh,
Could you tell me:
when should --linked be added?
(and when should --linked not be added?)
--
Best Regards
Masahiro Yamada