From: hlu%decserv1@dns1.eecs.wsu.edu Subject: Bug in 387 support and libm.a Reply-To: hlu%decserv1@dns1.eecs.wsu.edu Date: Sat, 25 Jan 1992 23:13:37 GMT Hi, I just ported dj's libm.a to Linux with a co-processor. I think I fixed a bug with the co-processor support. But I am not very sure what I am doing. Is anyone running Linux with a co-processor? i.e., 387 or 486DX. I can post the patches and the sources code for the library, or put them on nic and tsx-11, if necessary. I also added the detection for 486. But I was not able to test it (My PC is 386sx/387sx.). I have a suggestion. I think it would be nice to be able to load the 387 emulation stuffs during the booting time after the kernel finds out there is no 387. Or at least, the kernel can be made without it by just changing something in Makefile. I think I may want to do it if I have the time. I believe some 387 emulation code can be borrowed from dj's gcc/g++ for MS-DOS. BTW, could someone please tell me where I can find config files for compiling gcc. I need to compile gcc (gcc only, no cc1 and cpp) since the default of gcc I got is no 387. I keep forgetting to add -m80387. Thanks. H.J. -- School of EECS Internet: hlu@eecs.wsu.edu Washington State University BITNET: 60935893@WSUVM1.BITNET Pullman, WA 99164 Phone: (509) 335-6470 (O) USA
From: Hongjiu Lu -- Graduate Student < hlu@coea.wsu.edu> Subject: Re: Bug in 387 support and libm.a Reply-To: hlu@coea.wsu.edu Date: Mon, 27 Jan 1992 19:53:29 GMT | | In article < 1992Jan25.231337.9053@athena.mit.edu> you write: | > | >I just ported dj's libm.a to Linux with a co-processor. I think I | >fixed a bug with the co-processor support. | | Could you please elaborate? Was this in error handling/emulation or | what? Send diffs if you have access to them, so that it can be corrected | in the next version.. | | Linus | I think the bug about 387 is all the floating point exceptions are masked out. It may cause trouble for some math routines. I am still testing the 387 support. Beside the kernel, the compiler doesn't support 387. I found some strange things, like 1) double foo = 1.2234E34; does not work. Gcc translates it to foo = 1.2234. 2) foo = 0.0/0.0 hangs. No error reported. Is that a compiler bug or kernel bug? I am going to compile a new gcc and libc.a with 387 support. The current gcc and libc.a stink with 387. I hope I can finish it by this week. I will build a full libm.a for 387 and may add some entries to libc.a, like getpass (), etc. Any suggestions? BTW, has anyone added the system call, rename (), to libc.a? I'd like to have it in my libc.a. After some testing, I will put them on the ftp sites. For the machines with 387, it may need to recompile some programs. Because the kernel has to be modified to get 387 support, some programs may not run very well. I hope that will not be the case. I will test it first. Even if old programs works fine, recompile them is still a good idea to take advantage of 387. H.J. -- School of EECS Internet: hlu@eecs.wsu.edu Washington State University BITNET: 60935893@WSUVM1.BITNET Pullman, WA 99164 Phone: (509) 335-6470 (O) USA (509) 334-6315 (H)