public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "dje at google dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug gdb/17503] New: "mt set target-async on" breaks post hook routines Date: Tue, 21 Oct 2014 21:48:00 -0000 [thread overview] Message-ID: <bug-17503-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=17503 Bug ID: 17503 Summary: "mt set target-async on" breaks post hook routines Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: gdb Assignee: unassigned at sourceware dot org Reporter: dje at google dot com 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--- -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2014-10-21 21:48 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-10-21 21:48 dje at google dot com [this message] 2014-10-21 21:50 ` [Bug gdb/17503] " dje at google dot com 2014-10-21 21:50 ` dje at google dot com 2014-10-21 21:51 ` dje at google dot com 2014-10-21 21:56 ` dje at google dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-17503-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).