> grep'ed the tree for siglongjmp calls, and spotted possible offenders in > libssl's code. The code in question checks hardware capabilities for > ARM, S390x, and SPARCv9. > > The code will call some routines that could trigger SIGILL (or SIGBUS), > which is caught with an own signal handler. This signal handler will > perform the previously mentioned siglongjmp and jumps out of the > capability testing.
For the record, none of this code is enabled under OpenBSD. I will spare you my opinion of libraries registering signal handlers, because the amount of profanity I'd use is beyond the tolerance level of this list. All the information about the processor we run, and obtained by attempting to execute code and catch signals, has to be obtained from the kernel in a safe way (such as sysctl). Only the kernel will know that all the processors the library may run on, when running on a multiprocessor system, support the various instruction flavours. For a good example of this, see for example ppccap.c, although it is currently unused either. > It's difficult to write proper signal handlers, and even worse, I lack > machines of these types. "gcc -c" compiles the S390x and SPARCv9 files > for me, so there shouldn't be syntax errors. Yet I really need peer > reviews. If somebody dares to look at signals: Now is the time! :) I think now is the time to remove the S390x code, and work on documenting what the signal-based code attempts to know so that this code can be removed completely. (and this reminds me to add a few machdep sysctls to sparc64 so that I can tinker with the VIS Montgomery code...) Miod
