At Mon, 13 Jan 2003 11:36:50 +0000, David Goodenough wrote: > > On Monday 13 January 2003 10:44, Christoph Martin wrote: > > David Goodenough schrieb: > > > On Tuesday 05 November 2002 14:27, Daniel Jacobowitz wrote: > > >>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 <[EMAIL PROTECTED]> wrote: > > >>>>>>On Mon, Nov 04, 2002 at 09:23:16AM +0000, Ricardo Javier Cardenes > > >>>>>>Medina <[EMAIL PROTECTED]> 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. > > > > > > Well we have a disagreement between the kernel (which when you specify > > > C3 actually compiles everything march=i586) which reports in > > > /proc/cpuinfo that family = 6, and gcc. From all I can find out cmove is > > > an optional instruction for the 686, and if cmove was not used the code > > > would run on a C3. So either this is a kernel problem, and the C3 should > > > be reported as a 586, or it is a gcc problem for generating the wrong > > > code. Whoever is wrong, the end result is that libssl will not work as > > > shipped on any machine with a C3 in it - someone needs to fix it. > > > > > > I really do not care which package fixes it, as long as it gets fixed. > > > If we can get agreement on which package should fix it I am happy to see > > > if I can fix it, and I am quite prepared to test any fix, but I would > > > rather get agreement as to where the fix should be before I start, as at > > > the moment everyone is saying it is someone else's fault. > > > > Can we please come to a consense who is going to fix this! > > > > The VIA C3 is an official i686 and the kernel detects it as this. So it > > should be legitimate to compile it with -march=i686. But with > > -march=i686 gcc unconditionally includes CMOV commands which are > > optional in i686 per specification. > > > > So we have three possibilities > > > > - gcc stops using CMOV with i686 or includes a flag which turns of CMOV > > usage. > > - The kernel detects i686 processors as the C3 which do not support CMOV > > as i586 > > - The linker detects i686 processors as the C3 which do not support CMOV > > as i586 > > - libssl drops i686 optimisation and uses i586 for all i686 processors. > > > > If the kernel would change it we would have difficulties in specifying > > the dependencies correctly so that the users get not confused if they > > use an upstream kernel. So this is deprecated. > > Changing gcc in one of the ways would only require a Build-Depends on a > > special gcc version. > > Changing the linker would require a Depends on a special libc6 for i686. > > > > Cheers > > Christoph > > There have been some changes (I believe) in the kernel, at least on > Alan Cox's version - I am unsure whether it has made the official > 2.4 tree. It would be worth checking exactly what got changed and > which official kernel it comes with before making a decision on how > we close this bug.
Which kernel version do you check? I couldn't find such code... Resolving in the kernel is very clear for me, without downgrading all i686 binaries performance... Regards, -- gotom