This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug python/12930] GDB state during gdb.Breakpoint::stop callback isunclear


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]