GOTO Masanori schrieb:
> 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 <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.
>>>>
>>>>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...
I don't know where David checked ..
I just tried to find it. I found some performance optimisation for the
C3 in 2.4.20 but no special handling for the detected cpu familiy for
VIA processors. I also checked the -ac patch.
Christoph
Attachment:
pgphxMNlWudxM.pgp
Description: PGP signature