This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: divdi3: incomplete fix in db3d848e154b?
On 15/05/2017 15:30, Zack Weinberg wrote:
> 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.)
AFAIK glibc build system already does it, the problem is current abort
implementation pull more stuff that are meant only for libc.so. I think
we will need to create a ld.so specific version of abort (IS_IN(ld))
with a slight different semantic. Good thing is we already have
abort-instr.h which should be defined by all architectures (SH inclusive).
>
> 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?
Because we need to provide a compatibility symbols for some ABIs,
using libgcc.a won't help old binaries that calls divdi3 from libc.so.