Re: Bug#164766: Problem with VIA C3 chip and libcrypto
At 16 Jan 2003 18:38:07 +0000,
Philip Blundell wrote:
> So, per our IRC discussion this afternoon, I think the current plan for
> this is to have ld.so treat CMOV as an optional extension, similar to
> how MMX is handled. In other words:
>
> - Add CMOV to HWCAP_IMPORTANT in glibc.
>
> - Ask the maintainers of openssl and any other affected packages to put
> their cmov-using libraries in /lib/i686/cmov.
>
> - If openssl wants to ship a specific C3-compatible build that only
> uses mandatory i686 features, it can go in /lib/i686.
Thanks Philip for summarizing.
We debian-glibc team plan to prepare cmov-aware libc6.
To make sure for other people, I add some more words.
This libc ld.so special handling for hardware capability is used by
only MMX currently. We expand it not only for MMX but also CMOV.
MMX, intel's multi media extension, is also same circumstance that
both Pentium (i586) and Pentium MMX (i586 MMX) are 'i586 class
processors'.
Someone wonders why we don't change kernel /proc information. I was
noticed yesterday by James Troup on IRC that Dave Jones who are C3
kernel guy said his thought about it at lkml as follows:
At Wed, 15 Jan 2003 12:23:24 +0000,
Dave Jones wrote:
> On Wed, Jan 15, 2003 at 10:29:01AM +0100, Miklos Szeredi wrote:
> >
> > I just bought a VIA C3 866 processor, and under very special
> > circumstances some programs (e.g. mplayer, xmms) randomly crash with
> > trace/breakpoint trap or segmentation fault. Otherwise the system
> > seems stable even under high load.
>
> Be sure that those programs aren't compiled for 686. The C3 lacks
> cmov, so it'll segfault when it hits that opcode. You can confirm
> this by running it under gdb, and disassembling where it segv's to.
> This is still a common problem thats biting some people. The debian
> folks had a broken libssl for months up until recently.
>
> Note to userspace developers: If you're compiling something as
> a 686 binary, you *NEED* to check the feature flags (in an i386
> compiled program) to see if the CPU has cmov before you load 686
> optimised parts of your app. This is *NOT* a kernel problem,
> it is *NOT* a CPU bug. The cmov extension is optional.
> VIA chose to save silicon space by not implementing it.
> Gcc unfortunatly always uses cmov when compiling for 686.
>
> Dave
Well, his stance is not wrong.
We can hack gcc not to generate CMOV code with (for example) -mcpu=c3,
or -mno-cmov (like -mno-mmx), but stil this hardware capability
handling is needed for dynamic libraries.
In addition, We don't provide any cmov checking for 'binaries which
are hand-assembled or gcc generated'. Hand-assembled binaries should
check cmov flag like mmx. If you get 'illegal instruction' with such
binaries, you submit BTS for such packages. It's another issue that a
binary is optmized as i686 with cmov instruction by gcc. You need to
consider how to fix. I anticipate that it may need to make gcc
non-cmov aware.
Regards,
-- gotom
Reply to: