Re: Bug#164766: Problem with VIA C3 chip and libcrypto
- To: GOTO Masanori <gotom@debian.or.jp>
- Cc: Philip Blundell <pb@nexus.co.uk>, David Goodenough <david.goodenough@btconnect.com>, Christoph Martin <martin@uni-mainz.de>, debian-devel@lists.debian.org, 164766@bugs.debian.org, glibc@packages.debian.org, gcc@packages.debian.org
- Subject: Re: Bug#164766: Problem with VIA C3 chip and libcrypto
- From: Daniel Jacobowitz <dan@debian.org>
- Date: Fri, 17 Jan 2003 10:29:03 -0500
- Message-id: <[🔎] 20030117152903.GA9588@nevyn.them.org>
- Mail-followup-to: GOTO Masanori <gotom@debian.or.jp>, Philip Blundell <pb@nexus.co.uk>, David Goodenough <david.goodenough@btconnect.com>, Christoph Martin <martin@uni-mainz.de>, debian-devel@lists.debian.org, 164766@bugs.debian.org, glibc@packages.debian.org, gcc@packages.debian.org
- In-reply-to: <[🔎] 80u1g8k3sf.wl@oris.opensource.jp>
- References: <E187ksI-0004XZ-00@Beacon.Phantasia.org> <200211051503.gA5F3XR3029358@mailgate3.zdv.Uni-Mainz.DE> <[🔎] 3E229873.1020005@uni-mainz.de> <[🔎] E18Y2tm-0003Or-00@master.debian.org> <[🔎] 80iswpnrqe.wl@oris.opensource.jp> <[🔎] 1042742287.15234.32.camel@mill.nexus.co.uk> <[🔎] 80u1g8k3sf.wl@oris.opensource.jp>
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
Reply to: