This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: divdi3: incomplete fix in db3d848e154b?


On 05/15/2017 07:58 AM, Adhemerval Zanella wrote:

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).
But the issue I am pointing out here is not on SH - rather on architectures that still build divdi3.c, such as i686. And the issue is exactly that db3d848e154b fix does not get it right - it will result in a different signal being delivered than the one intended by the code.

Regards,
Alexey.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]