Date: Sat, 4 Oct 1997 00:49:48 +0200 From: Martin Cracauer <cracauer@cons.org> To: Bruce Evans <bde@zeta.org.au> Cc: cracauer@cons.org, jkh@time.cdrom.com, freebsd-current@FreeBSD.ORG, Matthew.Thyer@dsto.defence.gov.au, ports@FreeBSD.ORG Subject: Re: xlock: caught signal 8 while running galaxy mode. Message-ID: <19971004004948.45758@cons.org> In-Reply-To: <199710031905.FAA28989@godzilla.zeta.org.au>; from Bruce Evans on Sat, Oct 04, 1997 at 05:05:45AM %2B1000 References: <199710031905.FAA28989@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199710031905.FAA28989@godzilla.zeta.org.au>, Bruce Evans wrote: > >> I tried to convince people that FreeBSD hurts itself here, and the > >> dying screensavers are my primary example how this can hurt users. The > > Dying screensavers are a good example of why trapping on FP exceptions > is good: FP exceptions are often due to bugs, and trapping helps find > the bugs. Sure. But most free (and commercial) software has been developed and tested on machines that don't trap. So if applications show SIGFPE on FreeBSD, I can nothingtheless assume that either: a) The developer wrote the program expecting to get IEEE exceptional values and handles them just fine and just forgot to set the status in case the default isn't what he expects. Quite reasonable given the number of platforms that don't trap by default. b) The bugs don't matter. Many programs, especially free productivity tools use floating point just for nonimportant graphical effects, calculating progress bars and such. xlockmore is probably an example. Drawing something wrong isn't an important bug for a screen saver, dying is. c) I have no idea if the developer was aware of his floating point bugs, but the program is so useful for me that I have to assume that his testing on a nontrapping platform ensured that it is useable. I want to use it, preferrably without patching it first. Again, I think the killer argument is that a serious FP user is much more likely to be aware of the need to set the mask in case he needs traps as is a random user to be able to even recognize why his program dumps core. We could at least improve the error messages. > >> solution was to tell the port maintainers to switch FP mode for their > >> ports, which haven't happend for any port, as far as I know. > > According to "find /home/ncvs/ports -name 'patch-*' | xargs grep fpsetmask", > fpsetmask() is used in the following ports: > > Scilab, felt, mpeg2codec, vfghostscript > > and has been used in the following ports: > > tcl, tcl74. OK, didn't really look. Given the number of applications aware of the problem, we probably are best off changing bsd.port.mk to add a patch to set the mask by default. > >> There are bugs in our gcc that make relying on FP exceptions handled > >> right dangerous and Bruce Evans felt it is better to through the > >> signal, so that people get aware of the problem. > > I don't know of any bugs in gcc related to FP exceptions. > > >> With all respect to Bruce, I'm still conviced that we should switch to > >> default to set exceptional values and not signal the process. Our gcc > >> isn't that much worse than NetBSD's and Linux and those systems > >> obviously didn't get into trouble, at least not my my applications. > > How is our gcc worse than NetBSD's or Linux's? s/gcc/FreeBSD/ If I remeber correctly (and the one who told me was probably you), one can't disable FP exceptions easily without hiding stack exceptions as well. Behaviour for compile-time and runtime evaluation is different in quite a few places. There was something that we can't set errno (as we should accourding to POSIX) if we use IEEE non-trapping. Correct me if I'm wrong, but if we don't trap, these's little point in setting errno, isn't it? As I understand, we don't have working errno support anyway. So there's nothing to loose. The second problems about compile-and-runtime evalution is cleary only an issue for serious FP users. And trapping doesn't fix these bugs and the user can't do anything about them, it just make the user aware of them. For me, this isn't worth the trouble at other places. I'm not sure about the implications of the first issue. [...] > I decided not to commit the change to the control word until someone > fixes the error handling in lib/msun. Well, is there any agreement which standard to follow? Is plain IEEE reasonable? Maybe we can add a kernel config value to set the default mask? That way, we can't make npx.h reflect the real value, but I found no place in userland that uses it. Martin P.S.: To make it clear for other readers: I don't have a real clue about all the issues at hand, I just want a compatible default ignoring the problems. :-) -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer cracauer@wavehh.hanse.de (batched, preferred for large mails) Tel.: (daytime) +4940 41478712 Fax.: (daytime) +4940 41478715 Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971004004948.45758>