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).