Hello Jan, From: Jan Kratochvil Subject: Re: [RFC] "single step" atomic instruction sequences as a whole on PPC Date: Wed, 09 May 2007 20:33:19 +0200 > please check the attached two testcases and run them at least 100x etc. > > Unfortunately the threaded one fails for me in some 7% of cases IMO due to > a race at the `infrun.c' line: > remove_status = remove_breakpoints (); I'm not sure, but I guess the issue you may see on your testcase resembles to the session log below: -- GNU gdb 6.6.50.20070510-cvs Copyright (C) 2007 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc64-linux"... Using host libthread_db library "/lib64/libthread_db.so.1". (gdb) tb 161 Breakpoint 1 at 0x10001230: file gdb/testsuite/gdb.threads/atomic-seq-threaded.c, line 161. (gdb) r Starting program: gdb/testsuite/gdb.threads/atomic-seq-threaded [Thread debugging using libthread_db enabled] [New Thread 4160631792 (LWP 11609)] [New Thread 4160627904 (LWP 11612)] [Switching to Thread 4160631792 (LWP 11609)] main (argc=1, argv=0xffe92484) at gdb/testsuite/gdb.threads/atomic-seq-threaded.c:161 161 assert (i == 0); /* _create_behind_ */ (gdb) b 167 Breakpoint 2 at 0x1000126c: file gdb/testsuite/gdb.threads/atomic-seq-threaded.c, line 167. (gdb) b 151 Breakpoint 3 at 0x100011d0: file gdb/testsuite/gdb.threads/atomic-seq-threaded.c, line 151. (gdb) b 133 Breakpoint 4 at 0x10001120: file gdb/testsuite/gdb.threads/atomic-seq-threaded.c, line 133. (gdb) set can-use-hw-watchpoints 0 (gdb) watch unused Watchpoint 5: unused (gdb) c Continuing. [Switching to Thread 4160627904 (LWP 11612)] Breakpoint 4, start1 (arg=0x0) at gdb/testsuite/gdb.threads/atomic-seq-threaded.c:133 133 return arg; /* _delete1_ */ (gdb) d Delete all breakpoints? (y or n) y (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 4160631792 (LWP 11609)] 0x0ff3b748 in __libc_enable_asynccancel () from /lib/libc.so.6 (gdb) disassemble 0x0ff3b734 0x0ff3b750 Dump of assembler code from 0xff3b734 to 0xff3b750: 0x0ff3b734 <__libc_enable_asynccancel+52>: addi r9,r11,100 0x0ff3b738 <__libc_enable_asynccancel+56>: lwarx r10,0,r9 0x0ff3b73c <__libc_enable_asynccancel+60>: cmpw r10,r3 0x0ff3b740 <__libc_enable_asynccancel+64>: bne- 0xff3b74c <__libc_enable_asynccancel+76> 0x0ff3b744 <__libc_enable_asynccancel+68>: stwcx. r0,0,r9 0x0ff3b748 <__libc_enable_asynccancel+72>: bne- 0xff3b738 <__libc_enable_asynccancel+56> 0x0ff3b74c <__libc_enable_asynccancel+76>: isync End of assembler dump. -- If it is, the line in `infrun.c' you have pointed is not the cause. But whether it is or not, I think there is an issue for handling multiple trap events while doing software single stepping. In the testcase, GDB always does hardware single stepping by setting a software watchpoint. And when a thread running through an atomic sequence of instruction, it will be done by software one. So, during one thread is running through an atomic sequence of instructions, GDB can detects multiple SIGTRAP events on the target process, as you have already known. When that multiple SIGTRAP events occured, GDB selects one event and cancels the other if the cause of SIGTRAP is a breakpoint hit, or just leave it pended. The procedure will be done by `cancel_breakpoints_callback' in linux-nat.c. And the pended events will be deteced and noticed when the next time the target resumes. The probrem is that GDB doesn't check if the breakpoint is inserted for software single stepping when cancelling the trap event: when the event occured by a software single step breakpoint is not selected, GDB would not cancel it but leave it pended. When the next time the target resumes, GDB restores the pended event. But if you have removed the watchpoint that the target get stopped by before resuming, GDB can never decide the cause of SIGTRAP anymore. The session log above shows the phenomenon. I attach the source code modified from yours, Jan, which is much easier to reproduce the issue on my environment. And I'm so sorry for not sending any patch for resolving it, for my copyright assignment to FSF is STILL NOT ready. And Luis, it's just FYI: 'Emi' is one of common female names in Japan :-) -- Emi SUZUKI / emi-suzuki at tjsys.co.jp