On Fri, Jan 17, 2003 at 09:39:44AM +0900, GOTO Masanori wrote: > 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'.
This bit is a good idea but... > 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. Let's not do anything about this until someone gets clarification from GCC that -march=i686 is not actually supposed to be a 686, OK? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer