class ProcessBreakpoint

Given the initial Breakpoint object this corresponds to. Breakpoints can be added or removed

later.

Call Init() immediately after construction to initialize the parts that can report errors.

Call immediately after construction. If it returns failure, the breakpoint will not work.

Adds or removes breakpoints associated with this process/address. Unregister returns whether

there are still any breakpoints referring to this address (false means this is unused and

should be deleted).

When a thread receives a breakpoint exception installed by a process breakpoint, it must check

if the breakpoint was indeed intended to apply to it (we can have thread-specific breakpoints).

Notification that this breakpoint was just hit. All affected Breakpoints will have their stats

updated and placed in the *stats param. This makes a difference whether the exceptions was

software or hardware (debug registers) triggered.

All threads requested to be suspended (in any process) by this breakpoint's settings will be

filled into |other_affected_threads|.

IMPORTANT: The caller should check the stats and for any breakpoint with "should_delete" set,

remove the breakpoints. This can't conveniently be done within this call because it will cause

this ProcessBreakpoint object to be deleted from within itself.

Call before single-stepping over a breakpoint. This will remove the breakpoint such that it

will be put back when the exception is hit and BreakpointStepHasException() is called.

This will not execute the stepping over directly, but rather enqueue it within the process so

that each stepping over is done one at a time.

The actual stepping over logic is done by |ExecuteStepOver|, which is called by the process.

NOTE: From this moment, the breakpoint "takes over" the "run-lifetime" of the thread. This

means that it will suspend and resume it according to what threads are stepping over it.

When a thread has a "current breakpoint" its handling and gets a single step exception, it

means that it's done stepping over it and calls this in order to resolve the stepping.

This will tell the process that this stepping over instance is done and will call

|OnBreakpointFinishedSteppingOver|, which will advance the queue so that the other queued step

overs can occur.

NOTE: Even though the thread is done stepping over, this will *not* resume the suspended

threads nor the excepted (stepping over) thread. This is done on |StepOverCleanup|.

This is because there might be another breakpoint queued up and that breakpoint needs a

chance to suspend the threads before these are unsuspended from the previous breakpoint.

Otherwise we introduce a race between the current step over breakpoint resuming the

threads and the next one suspending them.

With the new order, the process will first call the next process |ExecuteStepOver|, which

will suspend the corresponding threads and then |StepOverCleanup| will free the

threads suspended by the current one.

Called by the queue-owning process.

This function actually sets up the stepping over and suspend *all* other threads. When the

thread is done stepping over, it will call the process |OnBreakpointFinishedSteppingOver|

function.

Frees all the suspension and exception resources held by the breakpoint. This is called by the

process.

See the comments of |EndStepOver| for more details.

Uninstalls this breakpoint from the given process' memory space. This process handle can be a

different process than the |process_| associated with this object. This is used to clean up

breakpoints after a Posix fork() call (since the installed breakpoints will be copied with

everything else, and we want to treat the processes independently).