real-i386 (was Re: i386 requalification for etch)
Frans Pop wrote:
> Do you mean that the security-flawed kernel patch would not have been
> needed?
Yes. For those interested, the full story is as follows.
gcc-3.3 contained inline functions in the C++ header atomicity.h -- included
by nearly every C++ program, and thus part of the binary interface -- which
used i486 assembly instructions. This was the root problem.
gcc-3.4 and gcc-4.0 have these as non-inline functions within the C++ standard
library with differing implementations for i386/i486/etc. depending on the
build of the C++ standard library. This is probably significantly slower,
but it means that the i486 assembly is not part of the C++ ABI any more.
However, in the wake of gcc-3.3, Debian switched to compiling for arch=i486 by
default (since real i386 was broken, it seemed like a good idea at the time
-- I may have been mistaken). I believe current GCC does not actually put
any other i486-dependent instructions into compilations (it reserves the
right to, but nobody's made it actually do so), so most programs compiled
like this should actually run on real i386.
However, vital libraries like glibc notice when they're being compiled for
i486 and use i486 assembly code, so the current archive won't run on real
i386.
The steps to restore real i386 support would be (sigh):
* Verify that the C++ ABI is now the same between i486 and i386.
* Change the default compilation options in gcc-3.4 and gcc-4.0, back to
--arch=i386. (--tune=i686 should be retained in all cases.) Deal with
fallout (gcc internal header files move, etc.).
* Attempt to make sure that GCC generates versions of libstdc++ for both i386
and i486, with linking choice made at runtime. I believe this is possible,
but it might require debugging the multilib configuration in libstdc++ for
x86, as I don't think anyone is doing this right now. (Otherwise i486+ would
suffer at runtime due to having to use the lousy i386 implementation of the
atomic locking instructions.)
* Recompile every package which used special assembly for i486. Wait for them
to get into testing.
* Restore real-i386 kernels to the archive (no emulation patches needed).
* Announce resumption of support.
I doubt that it's worth it, but that's the situation.
Reply to: