* H.J. Lu <hjl.tools@xxxxxxxxx> wrote: > > Yes, the .size directive not matching up is technically a bug, but it was not > > checked by binutils before, for *years* - and you cannot just flip a switch and > > break who knows how much code. > > > > You need to at least emit a warning for some time to give people a *chance* to > > fix bugs - not just stuff an incompatible binutils down their throat and break > > the kernel build for thousands of commits and break bisection. > > If kernel doesn't use/need symbol size, don't put it in assembly code. What does that have to do with the question i raised: that of binutils backwards (in)compatibility to be able to build the Linux kernel? > > 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. 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. 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
