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 12:48, Alexey Neyman wrote:
> 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.
I am aware, my point is db3d848e154b patch was to follow what Joseph
suggested: divdi3.c should be only present for binary compatibility
for architectures exporting those functions from glibc 2.0, not as
default. It is not to fix the expected exception (which is another
issue), but rather it was a side-effect of it.