* H.J. Lu <hjl.tools@xxxxxxxxx> wrote: > If I understand it correctly, the issue here is in some cases, for whatever > reason, the assembly input files can't be changed even if they are incorrect. Correct - not having to change the source code is *very* important during testing and in particular during bisection testing. This binutils change broke the kernel build (and hence bisection) for over 130,000 existing commits (none of which can be changed - history is append-only immutable), on CONFIG_XEN=y x86-64 kernels. Kernel bisection works like this: git bisect good v2.6.27 git bisect bad v2.6.37 The kernel gets rebuilt and tested by the tester at every commit that the bisection mechanism comes up with. Mid-section commits get marked either 'git bisect bad' or 'git bisect good', depending on whether the bug is experienced or not. Try it on a kernel repo, you can clone/track it: http://people.redhat.com/mingo/tip.git/README The Linux kernel has over 200,000 commits currently, with about 10,000 new commits per new release. Bisection can easily go 'back in time' a few ten thousand commits and can end up on any of those commits (depending on the kind of bug that is being bisected). You can try out the commands above. Please try it and mark commits good/bad randomly and see where you end up. You can end up *anywhere* within the 130,000+ commits bisection windo. This CONFIG_XEN=y example shows why it's a *seriously* bad idea for build infrastructure to introduce build failures out of the blue. We want build *warnings* to allow code that built fine before to still build. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
