Re: divdi3: incomplete fix in db3d848e154b?

[Zack Weinberg <zackw at panix dot com>]

There are two problems, and maybe we should talk about them independently.

One problem is that the compiler may insert __builtin_trap operations
to cause prompt crashes for UB - which is a Good Thing - but on
architectures where the back-end doesn't know how to generate a
hardware trap instruction, __builtin_trap produces a call to abort,
which is not available in ld.so.  This will only keep happening, and
there may be architectures that don't _have_ a guaranteed-invalid
opcode, so it's not fair to call it the compiler's problem.  Why
shouldn't we just move the one true definition of abort into ld.so?
(In fact, I would like to ask this question about _all_ functions that
are defined in both ld.so and libc.so.)

The other problem is that divdi3.c in particular should be generating
SIGFPE instead of SIGILL.  I think there's a case to be made that the
optimization GCC is doing is _incorrect_ for division by constant
zero, precisely because arithmetic emulation code needs a way to
produce a "true" divide-by-zero SIGFPE.  But why do we even _have_
divdi3.c?  On architectures where libc.so needs to expose __divdi3,
why are we not getting the definition from libgcc.a?

zw