Re: Bug#164766: Problem with VIA C3 chip and libcrypto
On Tuesday 05 November 2002 13:04, Christoph Martin wrote:
> Am Die, 2002-11-05 um 01.34 schrieb GOTO Masanori:
> > At Mon, 4 Nov 2002 11:07:56 +0100,
> > Oliver M. Bolzer <firstname.lastname@example.org> wrote:
> > > On Mon, Nov 04, 2002 at 09:23:16AM +0000, Ricardo Javier Cardenes
> > > Medina <email@example.com> wrote...
> > >
> > > > On Sun, Nov 03, 2002 at 12:13:07PM +0100, Michael Karcher wrote:
> > > > > take profit of these instructions, but It seems likely. Is there
> > > > > any way to select libraries based on 'instruction set' instead of
> > > > > architecture, so the VIA C3 could get code 'without cmov', the PII
> > > > > 'with cmov and MMX', the PIII 'with cmov, MMX and SSE' and an
> > > > > Athlon processor 'with cmov, MMX and 3D now!', although they all
> > > > > are 'family: 6'.
> > > >
> > > > See at the end of /proc/cpuinfo. The "flags" field. For my Duron:
> > > >
> > > > flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
> > > > cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
> > >
> > > The problem with OpenSSL is, that it is hand-assembly. The author is
> > > using the cmov instruction for an i686-optimized routine, though that
> > > instruction is not guranteed to be available.
> > I could not find which source cmov is used, could you tell me?
> > If it's the fact, openssl should be fixed in #164766.
> openssl does not use explicitly cmov. On all processors which are
> detected as i686 by the linker a library is used which is optimized via
> gcc and the -mcpu=i686 flag. This flag brings the cmov in I suspect.
> > > As another C3 user who has to keep libssl on hold for now, I'd suggest
> > > that the i686-optimized version be replaced with a version that runs on
> > > all i686-family processors.
> > > Another option would be to do runtime detection and choose according to
> > > that, but that would be without the current convenience that the linker
> > > chooses the right lib. As long as the linker only decids on the general
> > > processor type, the code for a specific processor type should match the
> > > least common denominator.
> > Yes. It's insane option that linker selects i586 library in only the
> > case of "flags: cmov" is detected on VIA C3. It means that linker
> > consider "C3 is i586". So, if kernel detects VIA C3, then it's natural
> > to be treated with i586 straightforwardly (thus /proc/cpuinfo prints
> > processor family: i586).
> This is what I said. The linker (glibc) should fix this.
The linker can not fix this. The C3 is a legitimate 686, it just does not
have the OPTIONAL cmov instruction. The kernel therefore correctly shows
this as a 686, and the linker tries the i686 directory (I presume). The
linker has no way of knowing whether the code in the i686 directory uses
this optional instruction or not and loads it blindly, hence the problem.
I am told (by Alan Cox) that GCC originally uses cmov for 686, before it
was realised that it was optional. However looking through google I have
not been able to establish when gcc fixed it, and if this fix is present
in any 2.9x gcc or only in 3.x. Maybe the maintainer of gcc would know
and he may also be able to backfit this fix if it is not in 2.9x