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

real-i386 (was Re: i386 requalification for etch

I sent a message about this earlier, but it seems to have gotten lost.
> On Saturday 08 October 2005 22:38, Nathanael Nerode wrote:
> > Disgustingly, I worked out that we could have revived real i386 support
> > for etch thanks to changes in gcc-3.4 and gcc-4.0 which nobody bothered
> > to advertise.  But it's too late now, since everything is built with
> > arch=i486.  :-P
Frans Pop wrote:
> Do you mean that the security-flawed kernel patch would not have been 
> needed?
Yes.  Details follow:

In gcc-3.3, the C++ headers contained inline functions which contained i486 
assembly, as part of the atomic opertations implementation.  Because they 
were inline functions which manipulated arbitrary shared data, they were part 
of the ABI.

In gcc-3.4 and gcc-4.0, these functions have been replaced with out-of-line 
functions, implemented in libstdc++.  They are therefore no longer part of 
the ABI; a libstdc++ which uses the i386 versions instead is a drop-in 
replacement.  (The out-of-line implementation is probably significantly 
slower, of course, for programs which need to do a lot of atomic locking.)

However, in the wake of gcc-3.3, Debian switched to using --arch=i486 by 
default.  Although GCC doesn't generate any other i486-only instructions, 
other programs and libraries -- such as glibc -- detect this and build 
i486-specific code.  So this would have to be reverted and all affected 
libraries rebuilt before i386 support could be restored.

It would also be advisable to make sure that libstdc++ was properly 
multilibbed, so that an i386 and an i486 version are both installed, with the 
correct version chosen at runtime (vaguely like glibc-i686, though I'd 
recommend both be installed at all times) -- otherwise an even larger 
slowdown would result due to using the quite-slow i386 locking routine on 
i486s and newer.

Of course, i386-specific kernels would also have to return to the archive.

I'm not at all sure this all is worth it, but it's possible now.

Nathanael Nerode  <neroden@twcny.rr.com>

Make sure your vote will count.

Reply to: