Launchpad has imported 6 comments from the remote bug at https://sourceware.org/bugzilla/show_bug.cgi?id=32278.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2024-10-15T17:22:03+00:00 Arnez-b wrote: GDB can run into an assertion failure when stepping into a trap on s390x. To reproduce, compile the following source with gcc -O3 -g -o div0 -lpthread div0.c ----------------- div0.c ----------------- int __attribute__ ((noinline)) divide_by_zero (int a) { int z = 0; return a / z; } int main () { return divide_by_zero (42); } ------------------------------------------ and run GDB like this: $ gdb -q div0 Reading symbols from div0... (gdb) b main Breakpoint 1 at 0x1001080: file div0.c, line 11. (gdb) r Starting program: /home/arnez/tmp/div0 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, main () at div0.c:11 (gdb) s divide_by_zero (a=a@entry=42) at div0.c:5 (gdb) s ../../gdb/infrun.c:2983: internal-error: resume_1: Assertion `pc_in_thread_step_range (pc, tp)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0x10cb8cf gdb_internal_backtrace_1 ../../gdb/bt-utils.c:121 0x10cb8cf _Z22gdb_internal_backtracev ../../gdb/bt-utils.c:167 0x154716f internal_vproblem ../../gdb/utils.c:421 0x154747f _Z15internal_verrorPKciS0_P13__va_list_tag ../../gdb/utils.c:501 0x170f2b5 _Z18internal_error_locPKciS0_z ../../gdbsupport/errors.cc:57 0x127c4f3 resume_1 ../../gdb/infrun.c:2983 0x127cc51 resume ../../gdb/infrun.c:2999 0x127cf77 keep_going_pass_signal ../../gdb/infrun.c:9103 0x1280639 process_event_stop_test ../../gdb/infrun.c:8209 0x1283293 handle_signal_stop ../../gdb/infrun.c:7332 0x12859b5 handle_inferior_event ../../gdb/infrun.c:6556 0x1287179 _Z20fetch_inferior_eventv ../../gdb/infrun.c:4698 0x170fb07 gdb_wait_for_event ../../gdbsupport/event-loop.cc:672 0x171092f _Z16gdb_do_one_eventi ../../gdbsupport/event-loop.cc:216 0x12d4cab start_event_loop ../../gdb/main.c:401 0x12d4cab captured_command_loop ../../gdb/main.c:465 0x12d8007 captured_main ../../gdb/main.c:1338 0x12d8007 _Z8gdb_mainP18captured_main_args ../../gdb/main.c:1357 0x10165d5 main ../../gdb/gdb.c:38 --------------------- Reply at: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2075204/comments/1 ------------------------------------------------------------------------ On 2024-10-15T17:32:02+00:00 Arnez-b wrote: Note that gcc compiles the function divide_by_zero to a single instruction: 10011c0: a7 f4 00 01 j 10011c2 <divide_by_zero+0x2> This is a special "branch-trap" that jumps into the trap instruction "00 01". When GDB gets control after stepping there, the PC points after that instruction, which is outside the function's range. Reply at: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2075204/comments/2 ------------------------------------------------------------------------ On 2024-10-16T10:43:32+00:00 Vries wrote: Sounds somewhat similar to PR31194. It would be good to know if the naive patch that was posted there also works for this example. Reply at: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2075204/comments/5 ------------------------------------------------------------------------ On 2024-10-16T15:16:40+00:00 Tromey-b wrote: (In reply to Andreas Arnez from comment #1) > This is a special "branch-trap" that jumps into the trap instruction "00 > 01". When GDB gets control after stepping there, the PC points after that > instruction, which is outside the function's range. I'd somewhat expect decr_pc_after_break to apply here. s390-tdep.c does: set_gdbarch_decr_pc_after_break (gdbarch, 2); Reply at: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2075204/comments/6 ------------------------------------------------------------------------ On 2024-10-16T15:17:26+00:00 Arnez-b wrote: (In reply to Tom de Vries from comment #2) > Sounds somewhat similar to PR31194. Yes, I guess it does. > It would be good to know if the naive patch that was posted there also works > for this example. If you mean Tom's patch in PR31194 comment 10, yes. In this case the following happens: Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000000010011c2 in ?? () (gdb) bt #0 0x00000000010011c2 in ?? () Backtrace stopped: frame did not save the PC In particular the assertion failure does not occur. Of course we're still not getting a valid backtrace. But GDB at least survives, so it's a significant improvement. Reply at: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2075204/comments/7 ------------------------------------------------------------------------ On 2024-10-16T15:51:41+00:00 Arnez-b wrote: (In reply to Tom Tromey from comment #3) > I'd somewhat expect decr_pc_after_break to apply here. Would that even cover all corner cases? If I replace the branch-trap by some other illegal instruction, a SIGILL instead of a SIGTRAP occurs and the PC is also not adjusted. Maybe the right solution (on s390x) for SIGILL as well as for SIGTRAP would be to take the backed-up PC from si_addr from the siginfo_t structure and not just rigidly decrease it from the current PC. Reply at: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/2075204/comments/8 ** Changed in: gdb Status: Unknown => Confirmed ** Changed in: gdb Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/2075204 Title: gdb on s390x chokes on divide-by-zero from chaos-marmosets Status in gdb: Confirmed Status in Ubuntu on IBM z Systems: Confirmed Status in gdb package in Ubuntu: Confirmed Bug description: To help in the development of apport we're using the chaos-marmosets set of binaries, which triggers various crashes. In particular, we're using /usr/bin/divide-by-zero which does as its name indicates, which naturally triggers a native crash. However, GDB fails on s390x. Note that for the following I have the debugging symbols from ddebs.ubuntu.com installed: ubuntu@glibc-proposed:/tmp$ gdb /usr/bin/divide-by-zero [snip] Reading symbols from /usr/bin/divide-by-zero... Reading symbols from /usr/lib/debug/.build-id/14/82d2d64c3383ca479f17bfd17b314295c99f13.debug... (gdb) run Starting program: /usr/bin/divide-by-zero [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Program received signal SIGTRAP, Trace/breakpoint trap. 0x000002aa00000814 in ?? () (gdb) bt #0 0x000002aa00000814 in ?? () #1 0x000003fff7d2baac in __libc_start_call_main (main=0x2aa00000690 <main>, main@entry=<error reading variable: value has been optimized out>, argc=argc@entry=1, argv=argv@entry=0x3ffffffa468) at ../sysdeps/nptl/libc_start_call_main.h:58 #2 0x000003fff7d2bbae in __libc_start_main_impl (main=<optimized out>, argc=1, argv=0x3ffffffa468, init=<optimized out>, fini=<optimized out>, rtld_fini=0x3fff7f85650 <_dl_fini>, stack_end=0x3ffffffa3b0) at ../csu/libc-start.c:360 #3 0x000002aa00000720 in _start () (gdb) info address divide_by_zero Symbol "divide_by_zero" is a function at address 0x2aa00000810. (gdb) So at this point GDB isn't capable of identifying the various symbols on the stack, which isn't ideal. Now, if I try to step in: ubuntu@glibc-proposed:/tmp$ gdb -q /usr/bin/divide-by-zero Reading symbols from /usr/bin/divide-by-zero... Reading symbols from /usr/lib/debug/.build-id/14/82d2d64c3383ca479f17bfd17b314295c99f13.debug... (gdb) start Temporary breakpoint 1 at 0x690: file divide-by-zero.c, line 29. Starting program: /usr/bin/divide-by-zero [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Temporary breakpoint 1, main (argc=1, argv=0x3ffffffa468) at divide-by-zero.c:29 warning: 29 divide-by-zero.c: No such file or directory (gdb) s 34 in divide-by-zero.c (gdb) divide_by_zero () at divide-by-zero.c:25 25 in divide-by-zero.c (gdb) /build/gdb-nviNEX/gdb-15.1/gdb/infrun.c:2982: internal-error: resume_1: Assertion `pc_in_thread_step_range (pc, tp)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0x2aa100a247f ??? 0x2aa104efce5 ??? 0x2aa104eff7f ??? 0x2aa10668c13 ??? 0x2aa102553db ??? 0x2aa10255bd1 ??? 0x2aa10255f5f ??? 0x2aa10259195 ??? 0x2aa1025c315 ??? 0x2aa1025e9a5 ??? 0x2aa10260015 ??? 0x2aa1066951b ??? 0x2aa10669e6d ??? 0x2aa102b01cd ??? 0x2aa102b3607 ??? 0x2aa0ffed839 ??? 0x3ffb142baab __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x3ffb142bbad __libc_start_main_impl ../csu/libc-start.c:360 0x2aa0fff8f8f ??? 0xffffffffffffffff ??? --------------------- /build/gdb-nviNEX/gdb-15.1/gdb/infrun.c:2982: internal-error: resume_1: Assertion `pc_in_thread_step_range (pc, tp)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) I can provide a core dump if you think that'd help, but it seems trivially reproducible. To manage notifications about this bug go to: https://bugs.launchpad.net/gdb/+bug/2075204/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
