This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug python/12930] GDB state during gdb.Breakpoint::stop callback isunclear
- From: "pedro at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Fri, 24 Jun 2011 13:44:31 +0000
- Subject: [Bug python/12930] GDB state during gdb.Breakpoint::stop callback isunclear
- Auto-submitted: auto-generated
- References: <bug-12930-4717@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=12930
Pedro Alves <pedro at codesourcery dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pedro at codesourcery dot
| |com
--- Comment #1 from Pedro Alves <pedro at codesourcery dot com> 2011-06-24 13:44:29 UTC ---
"(running)" is correct here. When the "stop" callback returns false, there
should be no running->stopped->running transition visible, exactly because your
callback claimed it didn't want the thread to "stop" (and nothing else wanted
it to stop).
>From the user/frontend's perspective, the thread is still running at this
point. [The user should get an error if he tries to resume a thread that
is currently "running", irrespective of the thread happening to be presently
suspended due to having hit some internal event (e.g., internal single-step
event stops while handling a "s" command that requires several single-steps).]
Internal events are hidden from the user. That's why we have running/stopped
independent of executing/not-executing in the thread's internal state.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.