Re: Bug#164766: Problem with VIA C3 chip and libcrypto
- To: David Goodenough <david.goodenough@btconnect.com>
- Cc: Christoph Martin <martin@uni-mainz.de>, GOTO Masanori <gotom@debian.or.jp>, debian-devel@lists.debian.org, 164766@bugs.debian.org, glibc@packages.debian.org
- Subject: Re: Bug#164766: Problem with VIA C3 chip and libcrypto
- From: Daniel Jacobowitz <dan@debian.org>
- Date: Tue, 5 Nov 2002 09:27:40 -0500
- Message-id: <[🔎] 20021105142740.GA20877@nevyn.them.org>
- Mail-followup-to: David Goodenough <david.goodenough@btconnect.com>, Christoph Martin <martin@uni-mainz.de>, GOTO Masanori <gotom@debian.or.jp>, debian-devel@lists.debian.org, 164766@bugs.debian.org, glibc@packages.debian.org
- In-reply-to: <[🔎] E1894Wk-00061N-00@master.debian.org>
- References: <E187ksI-0004XZ-00@Beacon.Phantasia.org> <80lm48am7e.wl@oris.opensource.jp> <[🔎] 1036501467.31053.37.camel@woodstock> <[🔎] E1894Wk-00061N-00@master.debian.org>
On Tue, Nov 05, 2002 at 02:17:40PM +0000, David Goodenough wrote:
> 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 <oliver@gol.com> wrote:
> > > > On Mon, Nov 04, 2002 at 09:23:16AM +0000, Ricardo Javier Cardenes
> > > > Medina <rcardenes@debian.org> 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.
> >
> > Christoph
>
> Christoph
>
> 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
GCC 3.2 still uses CMOVE instructions on -march=i686.
On the other hand:
{"c3", PROCESSOR_I486, PTA_MMX | PTA_3DNOW},
GCC disagrees with you that the C3 is an i686.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: