Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request From: metcalf@ircam.ircam.fr (Chris Metcalf) Newsgroups: comp.sys.sun Subject: 68881/Mcrt1.o problems with setitimer() Keywords: Software Message-ID: <499@ircam.UUCP> Date: 26 Apr 89 08:26:52 GMT Sender: usenet@rice.edu Organization: l'Institut de Recherche et Coordination Acoustique-Musique Lines: 41 Approved: Sun-Spots@rice.edu Original-Date: 7 Apr 89 14:46:42 GMT X-Sun-Spots-Digest: Volume 7, Issue 255, message 5 of 16 I've noticed a strange connection which perhaps someone could set me straight on. On a Sun 3 (SunOS 3.5) with a 68881, you can use gcc or cc -f68881 to get access to the 68881 chip. However, the Mcrt1.o library, which checks for and initializes the chip, seems to screw up the interval timer mechanism (!). Looking into the libc code (for minitfp) I find that commenting out the sigvec() call for the EMT trap during the chip initialization makes the program work fine on our Sun 3's. (Since there is no trap in that environment, it's safe.) But it's not just the sigvec call that causes the problem, since inserting it in the body of the test code doesn't cause any problems. Here's a 15-line code fragment to compile to see what I mean. Compiling it cc -fsoft works but doesn't use the chip; -f68881 uses the 68881 but the setitimer() returns EINVAL and the for-loop never exits; and -fswitch works and uses the 68881 but brings in lots of unnecessary code. #include #include main() { struct itimerval itv; extern exit(); itv.it_value.tv_sec = 2; itv.it_value.tv_usec = 0; (void) signal(SIGALRM, exit); if (setitimer(ITIMER_REAL, &itv, (struct itimerval *)0)) perror("setitimer"); for (;;); /* expect an interupt after two seconds */ } Please mail any fixes or workarounds to me, as well as cc'ing to SunSpots if it seems of sufficient interest. Thanks in advance, Chris Metcalf -- l'Institut de Recherche et de Coordination Acoustique-Musique metcalf%ircam@uunet.uu.net / ...!inria!ircam!metcalf / metcalf@ucbingre.bitnet