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