divdi3: incomplete fix in db3d848e154b?

[Alexey Neyman]

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.