On Sat, Mar 8, 2025 at 7:49 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Fri, 7 Mar 2025 at 19:54, Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote: > > > > On Fri, Mar 7, 2025 at 1:47 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > On Mon, 24 Feb 2025 at 14:21, Ard Biesheuvel <ardb+git@xxxxxxxxxx> wrote: > > > > > > > > From: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > > > > > > Kbuild supports an architecture specific Makefile.postlink file that is > > > > invoked for the vmlinux target after it has been built. This Makefile > > > > takes 'vmlinux' (which has just been built) as the target, and mangles > > > > the file and/or constructs other intermediate artifacts from it. > > > > > > > > This violates the general philosophy of Make, which is based on rules > > > > and dependencies, and artifacts that are rebuilt only when any of their > > > > dependencies have been updated. > > > > > > > > Instead, the different incarnations of vmlinux that are consumed by > > > > different stages of the build should be emitted as distinct files, where > > > > rules and dependencies are used to define one in terms of the other. > > > > > > In my understanding, the build rule of vmlinux is atomic > > because vmlinux embeds a timestamp and a build version. > > > > Now, you are splitting it into two stages. > > > > vmlinux.unstripped (this includes timestamp and the build version) > > --(cmd_strip_relocs)--> vmlinux > > > > > > When cmd_strip_relocs is changed, only vmlinux is updated. > > This changes the content of vmlinux, but its timestamp and build version > > remain the same. > > > > So, I am not sure if this is the right direction. > > > > You are saying that, when we change the contents of the > cmd_strip_relocs build rule and rebuild without cleaning, vmlinux will > have an older timestamp? I think there are many more cases where the > version is not updated, so I don't see this as a problem at all. For example please? > > > > > You can see more steps for updating vmlinux. > > Do you believe the build rule should be further split into > > more fine-grained stages? > > > > No. > > The problem is that vmlinux.relocs (in arch/x86/boot/compressed) > depends on vmlinux, but not the version of vmlinux that is ultimately > produced. Why? Is there any case where vmlinux and vmlinux.relocs become out of sync? > It should depend on an artifact that is always suitable to generate > the relocation table, not only during the short time between the > initial creation of vmlinux and the point during the execution of > Makefile.postlink where the relocations that are needed to generate > vmlinux.relocs are stripped from vmlinux. I still do not understand why this is a problem. arch/*/Makefile.postlink is invoked from $(call if_changed_dep,link_vmlinux)