This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: divdi3: incomplete fix in db3d848e154b?
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Alexey Neyman <stilor at att dot net>, libc-alpha at sourceware dot org
- Date: Mon, 15 May 2017 11:58:49 -0300
- Subject: Re: divdi3: incomplete fix in db3d848e154b?
- Authentication-results: sourceware.org; auth=none
- References: <e99d6df7-8cb2-282d-ffeb-fcc383db94be@att.net>
On 14/05/2017 03:22, Alexey Neyman wrote:
> Hi,
>
> I was compiling glibc (2.25 + d40dbe722f004) for sh4-unknown-linux-gnu and the build failed due to rtld pulling abort.os again. This has been "fixed" in master in db3d848e154b - which made divdi3 built only for certain architectures. However, I think this just masks the real issue that GCC7 inserts a trap where it knows something gets divided by zero.
>
> Here is a fragment of generated code for i686-unknown-linux:
>
> objdump -dlr csu/divdi3.os:
> /home/avn/work/ctng/crosstool-ng/.build/src/glibc-2.25/csu/../sysdeps/wordsize-32/divdi3.c:91
> d0: 85 db test %ebx,%ebx
> d2: 75 0c jne e0 <__udivmoddi4+0xe0>
> d4: 0f 0b ud2
>
> divdi3.c:
> 90 if (d0 == 0)
> 91 d0 = 1 / d0; /* Divide intentionally by zero. */
>
> Isn't the purpose of this intentional division to generate a SIGFPE, rather than SIGILL?
>
> Shouldn't divdi3.c do something else here, e.g. raise(SIGFPE) or be compiled with -fno-sanitize=integer-divide-by-zero?
>
> Regards,
> Alexey.
>
This is a known issue with GCC for SH [1], which still does not have support for
__builtin_trap. From last comments it is still in discussion if the trap will
use either the '#trap' instruction or a undefined instruction.
Unless we get an unconditional trap fix this fix will be a better effort in the
sense each new GCC version will bring potentially new analysis that might
generate the trap instructions for current code. So it is basically two efforts
here: fix/avoid any glibc code that might generate this kind of trap for SH
(d40dbe722f004 for instance) and check if the resulting gcc build actually
get it right (db3d848e154b fix for instance).
Another option could still requiring using GCC specific flags to build glibc
on SH (-fno-isolate-erroneous-paths-dereference and
-fno-isolate-erroneous-paths-attribute for instance). I would prefer to avoid
it and have a SH support from default headers (assuming gcc was not configured
to use them).
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216