On Thu, Jun 25, 2020 at 08:33:51PM +0200, Peter Zijlstra wrote: > On Thu, Jun 25, 2020 at 09:22:26AM -0700, Sami Tolvanen wrote: > > On Thu, Jun 25, 2020 at 09:47:16AM +0200, Peter Zijlstra wrote: > > > > Right, then we need to make --no-vmlinux work properly when > > > !DEBUG_ENTRY, which I think might be buggered due to us overriding the > > > argument when the objname ends with "vmlinux.o". > > > > Right. Can we just remove that and pass --vmlinux to objtool in > > link-vmlinux.sh, or is the override necessary somewhere else? > > Think we can remove it; it was just convenient when running manually. Great, I'll change this in v2. > > > > > > +ifdef CONFIG_STACK_VALIDATION > > > > > > +ifneq ($(SKIP_STACK_VALIDATION),1) > > > > > > +cmd_ld_ko_o += \ > > > > > > + $(objtree)/tools/objtool/objtool \ > > > > > > + $(if $(CONFIG_UNWINDER_ORC),orc generate,check) \ > > > > > > + --module \ > > > > > > + $(if $(CONFIG_FRAME_POINTER),,--no-fp) \ > > > > > > + $(if $(CONFIG_GCOV_KERNEL),--no-unreachable,) \ > > > > > > + $(if $(CONFIG_RETPOLINE),--retpoline,) \ > > > > > > + $(if $(CONFIG_X86_SMAP),--uaccess,) \ > > > > > > + $(@:.ko=$(prelink-ext).o); > > > > > > + > > > > > > +endif # SKIP_STACK_VALIDATION > > > > > > +endif # CONFIG_STACK_VALIDATION > > > > > > > > > > What about the objtool invocation from link-vmlinux.sh ? > > > > > > > > What about it? The existing objtool_link invocation in link-vmlinux.sh > > > > works fine for our purposes as well. > > > > > > Well, I was wondering why you're adding yet another objtool invocation > > > while we already have one. > > > > Because we can't run objtool until we have compiled bitcode to native > > code, so for modules, we're need another invocation after everything has > > been compiled. > > Well, that I understand, my question was why we need one in > scripts/link-vmlinux.sh and an additional one. I think we're just > talking past one another and agree we only need one. We need just one for vmlinux.o, but this rule adds an objtool invocation for kernel modules, which we also couldn't check earlier. We link all the bitcode for modules into <module>.lto.o and run modpost and objtool on that before building the final .ko. Sami