Re: linux-next: Tree for March 8 (BROKEN:arch/x86/kernel/entry_32.S? Debian's binutils/as?)

[Ingo Molnar]

* 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/