Message-ID: <CAK7LNASE7jn3t23MbB375ma-yJj6FhzqB_Zr+-+8NbeoYxCdmw@mail.gmail.com>
Date: Tue, 11 Mar 2025 18:52:13 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org, x86@...nel.org, 
	linux-kbuild@...r.kernel.org, Linus Torvalds <torvalds@...ux-foundation.org>, 
	Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH 0/4] x86/build: Get rid of vmlinux postlink step

On Tue, Mar 11, 2025 at 3:40 PM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Tue, 11 Mar 2025 at 03:39, Masahiro Yamada <masahiroy@...nel.org> wrote:
> >
> > On Sun, Mar 9, 2025 at 6:48 PM Ingo Molnar <mingo@...nel.org> wrote:
> > >
> > >
> > > * Ard Biesheuvel <ardb@...nel.org> wrote:
> > >
> > > > On Sat, 8 Mar 2025 at 17:17, Masahiro Yamada <masahiroy@...nel.org> wrote:
> > > > >
> > > > ...
> > > > > 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.
> > >
> > > Except when it doesn't work, such as when an intermediate linking step
> > > fails, and intermediate build products are lost and cannot be recreated
> > > easily (or at all without modifying the source)?
> > >
> > > And the thing is, there should be no such thing as an 'atomic build
> > > rule of vmlinux' if it means lost information when the build is broken
> > > at an intermediate step. What purpose does it have?
> > >
> > > > There is no make rule for vmlinux.relocs, and so
> > > >
> > > > - if it gets deleted, it cannot be rebuilt and even though the build
> > > > does not break, the relocation data is missing from the compressed
> > > > image, and this could potentially break the kaslr startup code,
> > > > - it vmlinux.relocs is older than vmlinux for some reason, make will
> > > > not notice and silently reuse the outdated version,
> > > > - when creating vmlinux.relocs from vmlinux and an error occurs,
> > > > vmlinux is deleted, making it difficult to diagnose the problem.
> > > >
> > > > I think this is badly broken, but if you think this is all working as
> > > > it should, I am not going to debate this further, and you can consider
> > > > the patch series withdrawn.
> > >
> > > That's very sad, as both the simplification is substantial:
> > >
> > >   19 files changed, 52 insertions(+), 87 deletions(-)
> > >
> > > and the increase in debuggability is substantial as well.
> > >
> > > Thanks,
> > >
> > >         Ingo
> >
> > When a byproduct is accidentally lost
> > (for example, manually deleted), it is not automatically restored.
> > Running 'rm vmlinux' or 'make clean' is needed.
> >
>
> Exactly. Make cannot detect this situation, and so the build breaks in some way.
>
> > vmlinux.relocs is one such byproduct.
> > Another is the map file when CONFIG_VMLINUX_MAP=y is enabled.
> >
>
> The linker map is not depended upon by other build targets, and is
> typically for human debug consumption, so while not ideal, it is not
> as broken as for the unstripped vmlinux.
>
>
> > I am a bit concerned about having more and more
> > intermediate vmlinux.* files, but maybe only me.
> > I hope vmlinux.unstripped is the only/last one.
> >
>
> Maybe we should not strip vmlinux at all, but only remove any static
> relocations when packaging? E.g., tar-pkg, etc
> >
> > OK, let's do this.
> >
> > Ard, please send v2 with .gitignore and 'clean' target updates.
> >
>
> Thanks, I'll prepare a v2, but in the meantime, can we think about not
> removing the relocations in the first place?

OK, let's try this approach.


--
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists