From owner-freebsd-current@freebsd.org Thu Feb 28 18:32:24 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1122F1512721 for ; Thu, 28 Feb 2019 18:32:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 89B4180B9A; Thu, 28 Feb 2019 18:32:22 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1SIWEFh017747 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 28 Feb 2019 10:32:14 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1SIWE7v017746; Thu, 28 Feb 2019 10:32:14 -0800 (PST) (envelope-from sgk) Date: Thu, 28 Feb 2019 10:32:14 -0800 From: Steve Kargl To: John Baldwin Cc: Conrad Meyer , freebsd-current Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd Message-ID: <20190228183214.GA17372@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 89B4180B9A X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.01 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; NEURAL_SPAM_SHORT(0.52)[0.517,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.29)[-0.288,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.05)[ip: (0.10), ipnet: 128.95.0.0/16(0.16), asn: 73(0.06), country: US(-0.07)]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[troutmask.apl.washington.edu]; NEURAL_SPAM_MEDIUM(0.05)[0.045,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 18:32:24 -0000 On Thu, Feb 28, 2019 at 09:09:38AM -0800, John Baldwin wrote: > On 2/23/19 8:39 AM, Steve Kargl wrote: > > On Sat, Feb 23, 2019 at 08:32:23AM -0800, Conrad Meyer wrote: > >> On Sat, Feb 23, 2019 at 12:44 AM Steve Kargl > >> wrote: > >>> Ideas? > >>> ... > >>> +CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) > >>> Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 > >> > >> https://ark.intel.com/content/www/us/en/ark/products/31728/intel-core-2-duo-processor-t7250-2m-cache-2-00-ghz-800-mhz-fsb.html > >> > >>> Intel® Virtualization Technology (VT-x) ‡ Yes > >>> Intel® 64 ‡ Yes > >> > >>> Merom is the first Intel mobile processor to feature Intel 64 architecture. > >> > >> So, as a workaround, maybe run amd64? > > > > This is the only i386 FreeBSD system that I have. This > > is the system where all the libm changes I've made have > > been tested. i386 floating point is different than > > amd64 floating point. See npx.c and the history of any > > of the long double functions that I've worked on. If > > this laptop does not run i386, there will be no testing > > of libm changes on the architecture. > > Yes, but we set the initial FPU control word for 32-bit binaries > to match i386 when running i386 binaries under an amd64 kernel. > > See these comments in sys/x86/include/fpu.h with which you are > likely familiar: > > /* > * The hardware default control word for i387's and later coprocessors is > * 0x37F, giving: > * > * round to nearest > * 64-bit precision > * all exceptions masked. > * > * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc > * because of the difference between memory and fpu register stack arguments. > * If its using an intermediate fpu register, it has 80/64 bits to work > * with. If it uses memory, it has 64/53 bits to work with. However, > * gcc is aware of this and goes to a fair bit of trouble to make the > * best use of it. > * > * This is mostly academic for AMD64, because the ABI prefers the use > * SSE2 based math. For FreeBSD/amd64, we go with the default settings. > */ > #define __INITIAL_FPUCW__ 0x037F > #define __INITIAL_FPUCW_I386__ 0x127F > #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__ > #define __INITIAL_MXCSR__ 0x1F80 > #define __INITIAL_MXCSR_MASK__ 0xFFBF > > And this code in ia32_setregs() in sys/amd64/ia32/ia32_signal.c > to set the initial register values for i386 processes: > > /* > * Clear registers on exec > */ > void > ia32_setregs(struct thread *td, struct image_params *imgp, u_long stack) > { > ... > pcb->pcb_initial_fpucw = __INITIAL_FPUCW_I386__; > ... > } > > This matches what exec_setregs() in sys/i386/i386/machdep.c does: > > /* > * Reset registers to default values on exec. > */ > void > exec_setregs(struct thread *td, struct image_params *imgp, u_long stack) > { > ... > pcb->pcb_initial_npxcw = __INITIAL_NPXCW__; > ... > } > > You can do all your tests directly on amd64 by just adding > "-m32" to compile i386 binaries against the libraries in /usr/lib32 > and you will generate the same i386 binaries as if you were building > on an i386 system. If you are a bit more paranoid, you can install > an i386 world and chroot into it and use that to test i386. I do this > myself (-m32) for testing i386 things. I also run i386 VMs under > bhyve on amd64 hosts. I'm not sure your laptop's CPU can run i386 > VMs though, and you don't need a VM to test userland-only changes > (I'm usually trying to test kernel changes). Interesting. Did not know I could use -m32 with any reliability. Setting up my testing environment may be a challenge as I use mpfr/gmp, so would need -m32 aware versions of those libraries. I normally install whatever the port collection offers for mpfr/gmp. I suppose I would need to install those independently to get multilib support. I would also need to compile 2 versions of my testing framework (ie., additional support library). The BIOS does have a enable/disable button for virtualization. During the great drm-legacy-kmod event of the last month, enabling virtualization locks up a i386 FreeBSD kernel very quickly. Perhaps, virtualization works under amd64. Guess I'll burn an image onto a memstick an d give it a whirl. > However, an amd64 kernel is going to be a more stable, better > supported kernel for running i386 binaries than an i386 kernel > at this point, and that will become even more true in the future. This is interesting as well. Does this mean that amd64 is now the only tier 1 platform and all other architectures are after thoughts? -- Steve