[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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: