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:

> On Wed, Mar 9, 2011 at 8:02 AM, Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> >> > This binutils change is breaking numerous upstream kernel builds (and is making
> >> > bisection with new binutils impossible) for no particular good reason: binutils
> >> > was capable to figure out the symbol name before this change.
> >>
> >> That is totally false. The old assembler just generates incorrect size and It
> >> couldn't read the programmer's mind to find the correct symbol name.
> >
> > Still it didnt make the kernel not build and it did not make the kernel not boot. It
> > at most confused some ELF symbol table - which the kernel does not need.
> >
> > So all i'm trying to point out to you is that you appear to be seeing the world in a
> > very binary way: 'broken' versus 'correct' and that it can be rather harmful if you
> > project that binary view on the real world that in reality is not binary but is
> > shades of grey.
> >
> > You are turning a benign ELF symbol table detail (that does not affect the kernel's
> > ability to boot/work) into a hard build breakage and bisection barrier, covering
> > hundreds of commits.
> 
> The original assembler change didn't mention the bogus symbol name in error 
> message, which is very unhelpful. I changed the assembler to print out the bogus 
> symbol name in error message. It should be very trivial to identify the bogus 
> kernel assembly codes.
> 
> > I'm not denying that it's buggy code - I'm just asking you to *PLEASE* at 
> > minimum acknowledge that surprise flag days that turn a before-benign condition 
> > into a fatal build failure suck to everyone else outside your own little 
> > universe.
> 
> There is no way for assembler to know if a bug in input source code is "benign" or 
> not. For assembler, a bug in input is a bug in input.  Assembly programmers should 
> appreciate this assembler change for helping him/her catch such bugs in his/her 
> codes.

I think you _still_ have not understood the very simple compatibility point i'm 
trying to make.

You are retroactively build-breaking kernel code that built and worked fine before. 
Your change could turn large sections of kernel history into a build-broken mess.

GCC does this more or less correctly: i can still build very old versions of the 
kernel even with latest GCC - i have recently bisected to and build v2.6.20 which is 
now a 4+ years old kernel, and had no problems building and booting such an old 
kernel, with a new GCC version.

GCC does this by trying to introduce new restrictions on successful compilation 
conservatively: if the compiler gets smarter and notices bugs (or potential bugs) it 
does not abort the build, it emits a warning instead.

Your "it's simple to fix" argument misses that point: i was talking about bisection 
breakage, and during bisection of kernel bugs we dive back into older versions of 
the code.

It does not matter that you declare the .size directive bogus. It is buggy and yes 
i've already queued up the fixes and i apprecitate them being fixed, but that's 
immaterial to the compatibility argument i made: BINUTILS BUILT THE KERNEL FINE 
BEFORE.

If you do changes to a major component of the build environment of thousands of free 
software projects you *must* consider the real-life compatbility effects of your 
change on others, not just your own motivation.

If you do that you need to at least UNDERSTAND what i'm talking about. It scares the 
heck out of me that we are here at mail #20 with a *very* simple compatibility 
scenario and the maintainer of a major piece of free software infrastructure *still* 
does not understand this very simple argument. How the heck will you be able to 
handle more complex cases of compatibility in a responsible way?

> [...] Assembly programmers should appreciate this assembler change for helping 
> him/her catch such bugs in his/her codes.

Sure, and a warning will have a similar effect and we'll appreciate it. Forcing a 
build error and retroactively breaking the build for working code out of blue, not 
so much.

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/