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
pgpLLyilkIQAX.pgp
Description: PGP signature
