Message-ID: <CAK7LNATkaTvAwPmNM3kSOCkCptW-bo9Ko6asWyFVcGYgu5rHtw@mail.gmail.com>
Date: Sun, 9 Mar 2025 01:17:07 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, linux-kbuild@...r.kernel.org, 
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [RFC PATCH 0/4] x86/build: Get rid of vmlinux postlink step

On Sat, Mar 8, 2025 at 7:49 PM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Fri, 7 Mar 2025 at 19:54, Masahiro Yamada <masahiroy@...nel.org> wrote:
> >
> > On Fri, Mar 7, 2025 at 1:47 AM Ard Biesheuvel <ardb@...nel.org> wrote:
> > >
> > > On Mon, 24 Feb 2025 at 14:21, Ard Biesheuvel <ardb+git@...gle.com> wrote:
> > > >
> > > > From: Ard Biesheuvel <ardb@...nel.org>
> > > >
> > > > 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)

>From Make's perspective, this is a single build rule
to generate vmlinux. For x86, vmlinux.relocs is
a byproduct. I do not see this as a problem.



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

Again, for example please.

The build rule of vmlinux is atomic.
When vmlinux is updated, its timestamp is updated.
When any part of the build rule fails, vmlinux is deleted
because we cannot keep an invalid vmlinux.
This process is quite simple.



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

I do not think it is broken.
As I mentioned above, I regard vmlinux.relocs as a byproduct
of the atomic build rule of vmlinux. This works.



--
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists