Re: [RFC PATCH 0/4] x86/build: Get rid of vmlinux postlink step

[Ard Biesheuvel]

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.

>
> 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.

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.

> For example,
>
> vmlinux.pre-sort  (this includes timestamp and the build version)
>    --(scripts/sortable)-->

Why? Which other artifact depends on the unsorted tables, and can no
longer be generated correctly after the tables have been sorted?

> vmlinux.unstripped
>    --(cmd_strip_relocs)-->
> vmlinux
>
> But, again, even when sorttable is changed,
> the timestamp and the build version remain the same.
>

Again, there are many other ways in which the final vmlinux can be
newer than the internal version fields suggest. I really don't think
this is an issue.

>
> Yeah, arch/*/Makefile.postlink is a crap
> where arch maintainers build a fence
> and start whatever they want to do.
>
> If they completely disappear, I would love it.
>

Good.

> However, this seems a partial clean-up
> within the scope you are interested in.
> (more specifically your motivation is because Linus pointed out
> a failure in arch/x86/Makefile.postlink deleted vmlinux)
>

Yes. Makefile.postlink failures propagate back to the build rule that
generates vmlinux, and so the file is deleted again.

For sanity checks performed on vmlinux, this is fine. But for
generating another file that takes vmlinux as its input, this is
completely broken.