https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83150
--- Comment #3 from Ben Longbons <b.r.longbons at gmail dot com> --- (In reply to Andrew Pinski from comment #1) > The signal handler will always be sync unless someone decides to do a kill > from the command line. You're assuming that no library ever calls abort(). Glibc certainly does, notably in its malloc() implementation. Also, there's SIGSEGV, which was pointed out *cannot* be handled synchronously. For that, you probably need to implement an `__attribute__((signal_safe))` as a slightly-extended version of `__attribute__((pure))`. Plus ... are you really willing to bet that *no* internal callers of abort() expect sane semantics? (In reply to Andrew Pinski from comment #2) > Plugins are not well defined in GCC. That excuse is getting *really* old. So far, the main difficulties I'm hitting are when GCC goes out of its way to be difficult. (and yet so far it's *still* easier to use than LLVM, though if this attitude of "we categorically refuse to fix bugs" continues, that might change) > Also system headers should not be > using abort really. Can you find one which uses abort? Why not? It's a perfectly legitimate function, and headers can implement anything as an inline function. And in the real world, some that *do*: libstdc++, libbfd, boost, LLVM ...
