[Bug libgcc/85967] New: [ARM] No unwinding support for division functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85967
Bug ID: 85967
Summary: [ARM] No unwinding support for division functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: la...@linux-mips.org
Target Milestone: ---
__aeabi_idiv is missing unwinding info, so backtrace stops there not providing
information where division by zero happened. Tested with gcc-5.4.0 and
gcc-7.3.1, but given the fact libgcc/config/arm/lib1funcs.S is not receiving
any updates, all gcc versions are affected.
Test case compiled with gcc-5.4.0:
$ arm-v7a-linux-gnueabi-gcc -o test -g -rdynamic -funwind-tables
-fasynchronous-unwind-tables -fno-omit-frame-pointer sigfpe_div0_bt.c
./test
Stack trace:
/lib/libc.so.6(+0x16a66) [0xb6e39a66]
/lib/libc.so.6(gsignal+0x23) [0xb6e47600]
The same test case using gcc-7.3.1 on x86_64:
$ gcc -o test -g -rdynamic -funwind-tables -fasynchronous-unwind-tables
-fno-omit-frame-pointer sigfpe_div0_bt.c
$ ./test
Stack trace:
./test(baz+0x16) [0x55ef13367dd0]
./test(bar+0x15) [0x55ef13367dfe]
./test(foo+0x15) [0x55ef13367e16]
./test(main+0xb8) [0x55ef13367ed1]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7ff3e4402a87]
./test(_start+0x2a) [0x55ef13367b5a]
Using following naive patch in attachment makes things better...
--- a/libgcc/config/arm/lib1funcs.S 2018-05-29 01:20:17.816878829 +0200
+++ b/libgcc/config/arm/lib1funcs.S 2018-05-29 01:28:04.697491881 +0200
@@ -1344,7 +1344,9 @@
ARM_FUNC_START div0
#endif
+ .fnstart
do_push {r1, lr}
+ .save {r1, lr}
mov r0, #SIGFPE
bl SYM(raise) __PLT__
RETLDM r1
@@ -1355,6 +1357,7 @@
#else
FUNC_END div0
#endif
+ .fnend
#endif /* L_dvmd_lnx */
#ifdef L_clear_cache
Stack trace:
/lib/libc.so.6(+0x16a66) [0xb6e19a66]
/lib/libc.so.6(gsignal+0x23) [0xb6e27600]
./test() [0x10eea]
./test(baz+0x13) [0x10b64]
I would welcome if ARM could unwind in this situation too as it makes
backtraces more meaningful given limited environment of typical arm embedded
board.
[Bug libgcc/85967] [ARM] No unwinding support for division functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85967 --- Comment #1 from Ladislav Michl --- Created attachment 44205 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44205&action=edit SIGFPE test case
[Bug libgcc/85967] [ARM] No unwinding support for division functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85967 --- Comment #2 from Ladislav Michl --- *** Bug 85966 has been marked as a duplicate of this bug. ***
[Bug libgcc/85966] New: [ARM] No unwinding support for division functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85966
Bug ID: 85966
Summary: [ARM] No unwinding support for division functions
Product: gcc
Version: unknown
Status: RESOLVED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: la...@linux-mips.org
Target Milestone: ---
Status: RESOLVED
Resolution: DUPLICATE
__aeabi_idiv is missing unwinding info, so backtrace stops there not providing
information where division by zero happened. Tested with gcc-5.4.0 and
gcc-7.3.1, but given the fact libgcc/config/arm/lib1funcs.S is not receiving
any updates, all gcc versions are affected.
Test case compiled with gcc-5.4.0:
$ arm-v7a-linux-gnueabi-gcc -o test -g -rdynamic -funwind-tables
-fasynchronous-unwind-tables -fno-omit-frame-pointer sigfpe_div0_bt.c
./test
Stack trace:
/lib/libc.so.6(+0x16a66) [0xb6e39a66]
/lib/libc.so.6(gsignal+0x23) [0xb6e47600]
The same test case using gcc-7.3.1 on x86_64:
$ gcc -o test -g -rdynamic -funwind-tables -fasynchronous-unwind-tables
-fno-omit-frame-pointer sigfpe_div0_bt.c
$ ./test
Stack trace:
./test(baz+0x16) [0x55ef13367dd0]
./test(bar+0x15) [0x55ef13367dfe]
./test(foo+0x15) [0x55ef13367e16]
./test(main+0xb8) [0x55ef13367ed1]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7ff3e4402a87]
./test(_start+0x2a) [0x55ef13367b5a]
Using following naive patch in attachment makes things better...
--- a/libgcc/config/arm/lib1funcs.S 2018-05-29 01:20:17.816878829 +0200
+++ b/libgcc/config/arm/lib1funcs.S 2018-05-29 01:28:04.697491881 +0200
@@ -1344,7 +1344,9 @@
ARM_FUNC_START div0
#endif
+ .fnstart
do_push {r1, lr}
+ .save {r1, lr}
mov r0, #SIGFPE
bl SYM(raise) __PLT__
RETLDM r1
@@ -1355,6 +1357,7 @@
#else
FUNC_END div0
#endif
+ .fnend
#endif /* L_dvmd_lnx */
#ifdef L_clear_cache
Stack trace:
/lib/libc.so.6(+0x16a66) [0xb6e19a66]
/lib/libc.so.6(gsignal+0x23) [0xb6e27600]
./test() [0x10eea]
./test(baz+0x13) [0x10b64]
I would welcome if ARM could unwind in this situation too as it makes
backtraces more meaningful given limited environment of typical arm embedded
board.
--- Comment #1 from Ladislav Michl ---
Not really sure why this bug was submitted twice. Marking this one as duplicate
with apologies. Thank you.
*** This bug has been marked as a duplicate of bug 85967 ***
[Bug c/68193] _Generic -Woverflow false alarm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193 Ladislav Michl changed: What|Removed |Added CC||la...@linux-mips.org --- Comment #6 from Ladislav Michl --- Created attachment 46391 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46391&action=edit Ternary if That ternary operator makes warning disappear. In the testcase 'gcc -Woverflow -o x x.c' gives: x.c:14:9: warning: unsigned conversion from ‘int’ to ‘unsigned char’ changes value from ‘1000’ to ‘232’ [-Woverflow] baz = 1000; ^~~~ x.c:16:9: warning: unsigned conversion from ‘int’ to ‘unsigned char’ changes value from ‘2000’ to ‘208’ [-Woverflow] baz = 2000; ^~~~ while 'gcc -DNO -Woverflow -o x x.c' silently ignores overflow. I would welcome any advice, how o properly categorize this bug, so eventually new bugreport will be created. Thank you.
[Bug libgcc/85967] [ARM] No unwinding support for division functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85967 --- Comment #4 from Ladislav Michl --- I do not have a copyright assignment in place with the FSF and I'm not even author of that patch. Adhemerval Zanella did the work (thank you again) and I added him to CC List. Patch itself needs improving as __aeabi_ldiv0 is called with a 'b' not with a 'bl', so the unwind information is still not really correct.
