On Sat, Dec 19, 2020 at 11:27 AM Niels Möller <ni...@lysator.liu.se> wrote:
> For the other one, > https://git.lysator.liu.se/nettle/nettle/-/merge_requests/15 "Use signal > to detect CPU features when getauxval() isn't available", can you > explain for which systems is that needed? In the current code, you > handle gnu/linux (depends on glibc, I guess), freebsd and aix. > > I hesitate adding signal code, because it seems a bit dangerous and > brittle for a library to modify signal handlers. In particular, I worry > about what happens to other threads, since sigaction modifies the > process-global signal handler. > > The fat setup code is otherwise threadsafe, under the assumption that > writes to a function pointer variable is atomic on the relevant > architecture. In the unlikely case that we get concurrent calls to > fat_init, both threads will get to the same conclusion and store > identical values in the target variables, so then it shouldn't matter in > which order (and how late) writes propagate to other cores. > > If there's some way to setup (and restore) a thread-local signal handler > for SIGILL, that would be safer, but I don't know if that's at all > possible. > fat-ppc.c uses getauxval() function to detect cpu features for Linux systems, the problem is that getauxval was introduced in glibc v2.16 which released in 2012 so in case fat option enabled, the build will fail for older glibc versions. To get around that, I implemented cpu features detection using signal in case an old glibc version been used but as you mentioned the signals work as process-based in UNIX and that could be problematic in this case for certain circumstances. However, I'm not aware of any approach to achieve thread-safety signal handling and even if such approach exists I think it won't be tempting to complicate such procedure in order to detect cpu features in this way. Do you have any suggestions here or we have to look for alternative solutions? regards, Mamone _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
