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

[H.J. Lu]

On Wed, Mar 9, 2011 at 11:17 PM, Ingo Molnar <mingo@xxxxxxx> wrote:

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

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.
On the other hand, this is the incorrect assembly input as far as assembler
is concern.  You can write a simple assembly wrapper to fix the assembly input
before sending it to the real assembler.  Yes, it may be a hassle.  I guess
it is the price you may have to pay when you can't fix your code.

FWIW, I can provide the assembler wrapper if needed.

-- 
H.J.
--
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/