derekbruening
commented
9 years ago From qin.zhao@gmail.com on June 08, 2011 08:20:25
Yes this is an annoying feature caused by GDB, I have seen many times whenever debugging a multithreaded application. Better document it somewhere. Other than that, sometimes GDB inserts many int3 which causes a trap on every instruction execution and makes the debugging impossible.
From bruen...@google.com on June 08, 2011 08:30:50
the __nptl_create_event routine, AFAICT, is used as part of the communication between pthreads and gdb. gdb seems to set a hidden breakpoint there. DR then decodes an int3 prior to ret (0xcc 0xc3) and puts it into the code cache. the debugger then hits a trap on every pthread_create or other place which calls __nptl_create_event. at that point, the app code is 0xf3 0xc3 (repz ret) and the int3 is no longer there, but DR has no way of detecting this change made by the debugger via the kernel. the debugger handles these traps so this is just an annoyance at this point but worth documenting.
interp: start_pc = 0x00007f21ada9e483 0x00007f21ada9e483 e8 48 e5 ff ff call $0x00007f21ada9c9d0 %rsp -> %rsp 0xfffffff8(%rsp) 0x00007f21ada9c9d0 cc int3
0x00007f21ada9c9d1 c3 ret %rsp (%rsp) -> %rsp end_pc = 0x00007f21ada9c9d2
Program received signal SIGTRAP, Trace/breakpoint trap.
(gdb) x/5i 0x00007f21ada9e483 0x7f21ada9e483 <__pthread_create_2_1+1827>: callq 0x7f21ada9c9d0 <__nptl_create_event>
(gdb) disas nptl_create_event Dump of assembler code for function nptl_create_event: 0x00007f21ada9c9d0 <+0>: repz retq End of assembler dump. (gdb) x/5bx 0x7f21ada9c9d0 0x7f21ada9c9d0 <__nptl_create_event>: 0xf3 0xc3 0x66 0x66 0x66
this is inside libpthread.so.0
Original issue: http://code.google.com/p/dynamorio/issues/detail?id=490