From owner-svn-src-all@freebsd.org Mon Oct 19 16:50:58 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78882A1802A; Mon, 19 Oct 2015 16:50:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 05466A3F; Mon, 19 Oct 2015 16:50:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t9JGooMh083532 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 19 Oct 2015 19:50:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t9JGooMh083532 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t9JGonHa083525; Mon, 19 Oct 2015 19:50:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 19 Oct 2015 19:50:49 +0300 From: Konstantin Belousov To: Bruce Evans Cc: Garrett Cooper , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r289332 - head/tools/regression/lib/msun Message-ID: <20151019165049.GM2257@kib.kiev.ua> References: <201510142022.t9EKMC1C088993@repo.freebsd.org> <20151015072039.GY2257@kib.kiev.ua> <20151015200157.I2174@besplex.bde.org> <20151017130907.GZ2257@kib.kiev.ua> <20151018032945.S2131@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151018032945.S2131@besplex.bde.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 16:50:58 -0000 On Sun, Oct 18, 2015 at 04:42:04AM +1100, Bruce Evans wrote: > On Sat, 17 Oct 2015, Konstantin Belousov wrote: > > > On Thu, Oct 15, 2015 at 10:12:03PM +1100, Bruce Evans wrote: > >> On Thu, 15 Oct 2015, Konstantin Belousov wrote: > >> > >>> On Wed, Oct 14, 2015 at 08:22:12PM +0000, Garrett Cooper wrote: > >>>> Author: ngie > >>>> Date: Wed Oct 14 20:22:12 2015 > >>>> New Revision: 289332 > >>>> URL: https://svnweb.freebsd.org/changeset/base/289332 > >>>> > >>>> Log: > >>>> Fix test-fenv:test_dfl_env when run on some amd64 CPUs > >>>> > >>>> Compare the fields that the AMD [1] and Intel [2] specs say will be > >>>> set once fnstenv returns. > >>>> > >>>> Not all amd64 capable processors zero out the env.__x87.__other field > >>>> (example: AMD Opteron 6308). The AMD64/x64 specs aren't explicit on what the > >>>> env.__x87.__other field will contain after fnstenv is executed, so the values > >>>> in env.__x87.__other could be filled with arbitrary data depending on how the > >>>> CPU-specific implementation of fnstenv. > >>> No Intel or AMD CPU write to __other field at all. > >> > >> No, they all do. > >> > >> Test on old i386 on old A64: > >> ... > > No, I did not thought about fegetenv() as executing FXSAVE instruction. > > I did knew that fegetenv() is a wrapper around FNSAVE, and I was completely > > sure that FNSAVE in the long mode, when executed by a 64bit program, > > never writes anything into the %eip/data offset portion of the FNSAVE > > area. I suspect that this was motivated by unavoidable 32-bitness of > > the store format. > > fegetenv() is actually a wrapper around FNSTENV, and FNSTENV is a subset > of FNSAVE. Yes, it was a thinko, which in fact does not change the relevant considerations. > > > I was unable to find a reference in either Intel SDM or in AMD APM which > > would support my statement. The closest thing is the claim that the FOP > > field is not filled, in the SDM. Still, I wonder how things are really > > arranged by hardware for FNSAVE in 64bit mode. > > Let's check FOP below. > > > Are your experiments below were done for the 32bit programs, or for 64bit ? > > Both FXSAVE and XSAVE area formats and rules would be irrelevant for the > > FreeBSD ABI. > > For amd64, I used the freefall default which I think is long mode, but > there is some magic for the pointer size (small model?) I am not sure I follow. Freefall is the native amd64 installation, and its userspace is 64bit. So the CPU is in long mode both in kernel and for the default userspace. > > BTW, -m32 has been broken on freefall for years. At least libgcc.a is > incompatible or not installed. What command line do you use, exactly ? Note that cc -m32 -static is not supported right now and probably would not be supported at all. > > >> ... > >> Modified state for fegetenv(): > >> X 0000005C 7F 12 00 00 00 00 80 1F FF FF FF FF 63 82 04 08 > >> --cw- -mxhi --sw- -mxlo --tw- -pad- ----fip---- > >> ----------------- > >> X 0000006C 1F 00 1D 05 A0 92 04 08 2F 00 FF FF > >> -fcs- -opc- ----foff--- -fds- -pad- > >> ----other[16]---------------------- > > FOP (opc) is clearly filled on i386 (32-bit mode). Which CPU is this ? Please look at the the Intel' SDM vol 1 8.1.9 Fopcode Compatibility Sub-Mode, which basically states that FOP is not filled starting with Core2. > > >> ... > >> Test on -current amd64 on Xeon (freefall): > >> ... > >> Later fegetenv(): > >> X 00000060 7f 03 ff ff 00 00 ff ff ff ff ff ff 75 08 40 00 > >> X 00000070 43 00 1c 05 20 62 60 00 3b 00 ff ff 80 1f 00 00 > > FOP is filled to 1c 05 on freefall and to 1D 05 on my old i386. But the > instruction is the same (fstpl). The difference is a different encoding > of the direct address mode. > > Futher testing: > > Only small model seems to be supported. I got relocation errors with > messages about R_X86_64_32S for an array of size 4G. Do you mean that -mcmodel=medium or large does not work ? > > malloc() works to allocate arrays larger than 4G. Writing to addresses > above 4G in such arrays or on the stack never gave 64-bit offsets. > It truncated the offsets to 32 bits and still printed the segment > register. Please show exact transcript of the session.