The current way we implement post hook routines does not work with mt set target-async on. The hook is called long before the command actually completes, and in particular before the current thread is marked as no longer executing, which breaks one of my user's post hooks. Testcase will be attached. Below are sessions with target-async = off/on. Repro steps: bash$ gcc -g hookpost-step.c hookpost-step-2.c -o hookpost-step.x64 bash$ gdb hookpost-step.x64 (gdb) file hookpost-step.x64 (gdb) source hookpost-step.gdbinit (gdb) # set debug infrun 1 (gdb) # set debug lin-lwp 1 (gdb) # mt set target-async off or on (gdb) start (gdb) step Here's the session with target-async = off. ---snip-target-async-off--- (gdb) start Temporary breakpoint 1 at 0x4004f1: file hookpost-step.c, line 7. Starting program: /home/dje/src/play/hookpost-step.x64 Temporary breakpoint 1, main () at hookpost-step.c:7 7 foo (); (gdb) step foo () at hookpost-step-2.c:4 4 } hookpost-step called ... (gdb) finish main () at hookpost-step.c:8 8 return 0; ---- (gdb) step 9 } ---- ^^ skipped 1 functions ^^ ---- #0 main () at hookpost-step.c:9 9 } (gdb) ---end-snip-target-async-off--- Here's the session with target-async = on. ---snip-target-async-on--- (gdb) start Temporary breakpoint 2 at 0x4004f1: file hookpost-step.c, line 7. Starting program: /home/dje/src/play/hookpost-step.x64 Temporary breakpoint 2, main () at hookpost-step.c:7 7 foo (); (gdb) step hookpost-step called ... Traceback (most recent call last): File "<string>", line 3, in <module> gdb.error: No frame is currently selected. Error while executing Python code. (gdb) foo () at hookpost-step-2.c:4 4 } ---end-snip-target-async-on--- Also note that in the target-async on case we got the (gdb) prompt and then further output was produced. Turning infrun and lin-lwp debug flags on provides more information. In the "target-async = off" session, the hook is called after gdb notices we've stepped into a subroutine (which is as expected). ---snip--- (gdb) step infrun: clear_proceed_status_thread (process 13427) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 13427] at 0x4004f1 LLR: Preparing to step process 13427, 0, inferior_ptid process 13427 LLR: PTRACE_SINGLESTEP process 13427, 0 (resume event thread) infrun: wait_for_inferior () [... lots of output elided ...] infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400506 infrun: BPSTAT_WHAT_STEP_RESUME infrun: stepped into subroutine infrun: stop_waiting foo () at hookpost-step-2.c:4 4 } hookpost-step called ... ---end-snip--- In the "target-async = on" session, the hook is called after the first PTRACE_SINGLESTEP. Yikes. ---snip--- (gdb) step infrun: clear_proceed_status_thread (process 13539) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 13539] at 0x4004f1 LLR: Preparing to step process 13539, 0, inferior_ptid process 13539 LLR: PTRACE_SINGLESTEP process 13539, 0 (resume event thread) sigchld hookpost-step called ... Traceback (most recent call last): File "<string>", line 3, in <module> gdb.error: No frame is currently selected. Error while executing Python code. (gdb) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 13539, No child processes LLW: waitpid 13539 received Trace/breakpoint trap (stopped) LLW: Candidate event Trace/breakpoint trap (stopped) in process 13539. [... lots of output elided ...] ---end-snip---
Created attachment 7840 [details] testcase part 1
Created attachment 7841 [details] testcase part 2
Created attachment 7842 [details] testcase gdbinit
I'm thinking there's no need to block 7.8.1 for this. A workaround is to do "mt set target-async off".