FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F8.4.0 2012-06-13T15:25:52Z 2012-06-13T15:25:52Z John Baldwin jhb@FreeBSD.org 2012-06-13T15:25:52Z urn:sha1:84e1975986c540ece66f0721435dea181c7d9a62 232520 (partial),235563: Add support for the extended FPU states on amd64, both for native 64bit and 32bit ABIs. As a side-effect, it enables AVX on capable CPUs. In particular: - Query the CPU support for XSAVE, list of the supported extensions and the required size of FPU save area. The hw.use_xsave tunable is provided for disabling XSAVE, and hw.xsave_mask may be used to select the enabled extensions. - Remove the FPU save area from PCB and dynamically allocate the (run-time sized) user save area on the top of the kernel stack, right above the PCB. Reorganize the thread0 PCB initialization to postpone it after BSP is queried for save area size. - The dumppcb, stoppcbs and susppcbs now do not carry the FPU state as well. FPU state is only useful for suspend, where it is saved in dynamically allocated suspfpusave area. - Use XSAVE and XRSTOR to save/restore FPU state, if supported and enabled. - Define new mcontext_t flag _MC_HASFPXSTATE, indicating that mcontext_t has a valid pointer to out-of-struct extended FPU state. Signal handlers are supplied with stack-allocated fpu state. The sigreturn(2) and setcontext(2) syscall honour the flag, allowing the signal handlers to inspect and manipilate extended state in the interrupted context. - The getcontext(2) never returns extended state, since there is no place in the fixed-sized mcontext_t to place variable-sized save area. And, since mcontext_t is embedded into ucontext_t, makes it impossible to fix in a reasonable way. Provide a sysarch(2) facility to query extended FPU state. - Add API for obtaining extended machine context states that cannot be fit into existing mcontext_t. On i386 and amd64 return the extended FPU states using getcontextx(3). For other architectures, getcontextx(3) returns the same information as getcontext(2). - Add ptrace(2) support for getting and setting extended state; while there, implement missed PT_I386_{GET,SET}XMMREGS for 32bit binaries. - Change fpu_kern KPI to not expose struct fpu_kern_ctx layout to consumers, making it opaque. Internally, struct fpu_kern_ctx now contains a space for the extended state. Convert in-kernel consumers of fpu_kern KPI both on i386 and amd64. Reviewed by: kib 2011-12-30T18:22:34Z Konstantin Belousov kib@FreeBSD.org 2011-12-30T18:22:34Z urn:sha1:4f0d5efa7c0687deb8af73a271e7afd40f82a7cd Make sure that stack is 16-byte aligned before calling a function, as it is required by amd64 ABI. Add a comment for the places were the stack is accidentally properly aligned already. PR: amd64/162214 2008-11-09T10:45:13Z Ed Schouten ed@FreeBSD.org 2008-11-09T10:45:13Z urn:sha1:a1b5a8955e828f049b425b7b2141999823059923 Looking at our source code history, it seems the uname(), getdomainname() and setdomainname() system calls got deprecated somewhere after FreeBSD 1.1, but they have never been phased out properly. Because we don't have a COMPAT_FREEBSD1, just use COMPAT_FREEBSD4. Also fix the Linuxolator to build without the setdomainname() routine by just making it call userland_sysctl on kern.domainname. Also replace the setdomainname()'s implementation to use this approach, because we're duplicating code with sysctl_domainname(). I wasn't able to keep these three routines working in our COMPAT_FREEBSD32, because that would require yet another keyword for syscalls.master (COMPAT4+NOPROTO). Because this routine is probably unused already, this won't be a problem in practice. If it turns out to be a problem, we'll just restore this functionality. Reviewed by: rdivacky, kib 2008-11-02T01:10:54Z Peter Wemm peter@FreeBSD.org 2008-11-02T01:10:54Z urn:sha1:5d053f461caeb73f6de165aa1e07b2003101605c is used to set the ELF size attribute for functions. It isn't normally critical but some things can make use of it (gdb for stack traces). Valgrind needs it so I'm adding it in. The problem is present on all branches and on both i386 and amd64. 2008-06-28T17:55:43Z David Schultz das@FreeBSD.org 2008-06-28T17:55:43Z urn:sha1:64c2e4665060b5f4d83a14802f551d881ab3bc0a 1. Save and restore the control part of the MXCSR in addition to the i387 control word to ensure that the two are consistent. Note that standards don't require longjmp to restore either control word, and none of Linux, MacOS X 10.3 and earlier, NetBSD, OpenBSD, or Solaris do it. However, it is historical FreeBSD behavior, and bde points out that it is needed to make longjmping out of a signal handler work properly, given the way FreeBSD clobbers the FPU state on signal handler entry. 2. Don't clobber the FPU exception flags in longjmp. C99 requires them to remain unchanged. 2008-01-17T16:39:07Z Bruce Evans bde@FreeBSD.org 2008-01-17T16:39:07Z urn:sha1:d2012f333362e46e807f43b56f29b4a2c98441c3 instead of 32+32+15+1) on all arches that have such long doubles (amd64, ia64 and i386). Large objects should be be accessed in large units, and the 32+32+15+1[+padding] decomposition asks for almost the opposite of that, sometimes resulting in very slow accesses depending on how well the compiler ignores what we ask for and converts to the best units for the given machine. E.g., on Athlons, there is a 10-20 cycle penalty for accessing the middle 32-bit word immediately after an 80-bit store. Whether actually using the alternative view is better is very machine- dependent. A 32+32+16 view is probably best with old 32-bit systems and gcc through 4.2.1. The compiler should mostly avoid the view and generate best accesses, but gcc-4.2.1 is far from doing that. I think 64+16 is best for now. Similarly for doubles -- they should be using 64+0 especially on 64-bit machines, but fdlibm uses 32+32 extensively for them. Fortunately, in 64-bit mode for doubles, gcc already ignores the 32+32-bit view and generates best accesses in many cases. 2007-12-18T23:46:32Z David Schultz das@FreeBSD.org 2007-12-18T23:46:32Z urn:sha1:7cd4a832675ea6d396dcb5f7688ac58f4b4645c6 my original implementation made both use the same code. Unfortunately, this meant libm depended on a vendor header at compile time and previously- unexposed vendor bits in libc at runtime. Hence, I just wrote my own version of the relevant vendor routine. As it turns out, mine has a factor of 8 fewer of lines of code, and is a bit more readable anyway. The strtod() and *scanf() routines still use vendor code. Reviewed by: bde 2007-12-16T21:15:57Z David Schultz das@FreeBSD.org 2007-12-16T21:15:57Z urn:sha1:39e7abef0efd0d8e789a1237dafff9d8402d932b libm can use it. 2007-12-16T21:15:09Z David Schultz das@FreeBSD.org 2007-12-16T21:15:09Z urn:sha1:199cdab56f8d227f1dd7e1271fa4b4a8d9d92faf the NaN returned by strtod("nan()", NULL). 2007-12-03T07:17:33Z David Schultz das@FreeBSD.org 2007-12-03T07:17:33Z urn:sha1:9c90f85a6b0b7fe3c2b8fd68b72c46527e444bdc