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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
