Messages in this thread |  | | | Subject | Re: Why all glibc2 programs are FPU programs | | From | Ulrich Drepper <> | | Date | 26 May 1998 09:48:52 -0700 |
| |
"David S. Miller" <davem@dm.cobaltmicro.com> writes:
> Because the solution I propose allows anyone using any kernel existing > right now to have something which works. Your solution requires a > kernel upgrade and changes to both glibc and the kernel.
How many people do upgrade their libc more often than the kernel? I would be very surprised if this is more than 50%.
> I've been watching glibc set the FPU csr to zero on all architectures, > most of which give the user a zero'd FPU csr when it starts up, for > every process which ever runs, annulling any optimizations I do to
I agree that currently the instructions do effectively nothing for most processes. But what happens if the kernel changes the init values, that's the point. If you have all the code in one place this is no problem. But requiring synchronization between the kernel and the libc is exactly what everybody wants to avoid.
I agree completely that changing the startup code is the easiest way to fix the problem for the moment. But we simple trigger a timebomb. Encapsulate all the needed information in one place.
There is one more solution: let the kernel report what CW value it will use. Maybe in the ELF auxiliary vector. Add AT_LINUX_FPUCW and pass the value up. Then the libc can decide whether it is necessary to perform the operation or not. And we have no dependencies except that you need to upgrade your system to take advatnage of the improvements but this is the same for most enhancements.
-- Uli ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
|  |