[Bug other/83150] GCC's internal use of `abort`is unsafe in several ways

["b.r.longbons at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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 ...