From owner-cvs-src@FreeBSD.ORG Thu Mar 18 07:24:44 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42B7416A4CE; Thu, 18 Mar 2004 07:24:44 -0800 (PST) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id A82E043D2D; Thu, 18 Mar 2004 07:24:43 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd01.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1B3zNy-0007FV-02; Thu, 18 Mar 2004 16:24:42 +0100 Received: from Andro-Beta.Leidinger.net (EqNHq2ZeQeEBPmt5QhwInV-vcJ02+h7c-XLUwEhBirpNb9DldCserI@[80.131.124.200]) by fmrl01.sul.t-online.com with esmtp id 1B3zNP-1oQnnk0; Thu, 18 Mar 2004 16:24:07 +0100 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i2IFNxUA091321; Thu, 18 Mar 2004 16:23:59 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (netchild@localhost [127.0.0.1]) i2IFNwXI060030; Thu, 18 Mar 2004 16:23:58 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Thu, 18 Mar 2004 16:23:58 +0100 From: Alexander Leidinger To: obrien@freebsd.org Message-Id: <20040318162358.3f57aef3@Magellan.Leidinger.net> In-Reply-To: <20040318002208.GC2541@dragon.nuxi.com> References: <200403122136.i2CLaCm9096276@repoman.freebsd.org> <20040315033213.GA40858@dragon.nuxi.com> <20040315180324.0fa39609@Magellan.Leidinger.net> <20040318002208.GC2541@dragon.nuxi.com> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: EqNHq2ZeQeEBPmt5QhwInV-vcJ02+h7c-XLUwEhBirpNb9DldCserI@t-dialin.net cc: Tom Rhodes cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/share/mk bsd.cpu.mk bsd.dep.mk bsd.lib.mk bsd.sys.mk src/sys/conf files kern.mk kern.pre.mk kmod.mk src/sys/dev/aic7xxx/aicasm Makefile X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 15:24:44 -0000 On Wed, 17 Mar 2004 16:22:08 -0800 "David O'Brien" wrote: > On Mon, Mar 15, 2004 at 06:03:24PM +0100, Alexander Leidinger wrote: > > > > Problems with icc v8: > > > > - panic: npx0 cannot be emulated on an SMP system > > > > - UP: first start of /bin/sh results in a FP exception > > > > > > You forgot the other problems with icc v8 -- Intel's preditorial > > > behavior. Note that some parts of the Intel compilers support libs do a > > > CPUID call and if it notes an AMD CPU either segfaults or dumbs down the > > > capabilities of the CPU to that of the original i386. > > > > AFAIK: > > - only if the compiled binary contains the main function > > (the kernel doesn't) > > - only if you use a specific compiler option, which I don't use here > > It happens in several circumstances, not just when using one particular > compiler option. It seems I'm talking about a different part of the behavior than you do. > > BTW.: AFAIK it doesn't segfault, it exit()s. > > BTW, icc v8 produced binaries will sometimes segfault on AMD processors. > Trust me, AMD has tested this issue more than you have. Then the check I mentioned is buggy in the sense of "it does not protect all cases from segfaulting". It seems Intel identified some issues regarding icc when used on AMD processors. I don't know if there is malicious intend to use some specific instructions or not. I don't know if there exist instructions which perform the same action with the same efficiency (I don't define what "efficient" means in this case) without resulting in a segfault on AMD processors. It would be nice, if icc would produce code which also runs without flaws on AMD processors, but I can't influence such decisions, as I don't have any relationship with Intel (I just got the commercial license of icc for FreeBSD because I asked for it). If you are able to provide access to a similar good compiler for (a subset of) the ia32 architecture, I'm willing to give it a try too. ATM I'm working with Tom Rhodes and Bruce Evans to change the compiler tests to feature tests. Support for another compiler should be very easy to add then. > > Any manufacturer is free to limit the use of his programs as he wants. I > > agree, this behavior isn't nice, but life isn't nice either (sometimes). > > Then I'd like to take the stance of reanble the blind use of EFER.NXE in > the FreeBSD/amd64 loader -- Intel ia32e can just add that feature. It seems you're aware that this causes problems on Intel processors. Enabling the use of it is questionable then. Intel at least seems to be aware of some issues and protects the user from misbehavior. The test may be not strict enough in some cases, and maybe too strict in other cases, but as long as you can't proof they do this with malicious intend, you should try to calm down. Bye, Alexander. -- I will be available to get hired in April 2004. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7