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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2075204 Title: gdb on s390x chokes on divide-by-zero from chaos-marmosets To manage notifications about this bug go to: https://bugs.launchpad.net/gdb/+bug/2075204/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
