class Process

Returns the target associated with this process. Guaranteed non-null.

The Process koid is guaranteed non-null.

Returns the "name" of the process. This is the process object name which is normally based on

the file name, but isn't the same as the file name.

Returns the component information.

Returns the interface for querying symbols for this process.

Returns true if this process has loaded at least one module, false otherwise.

Provides a high level "how are symbols doing" for this process. In the happy case, where

everything is loaded and ready to go, this function will return |kLoaded|. If this is called

before `GetModules` has been called, |kNoModules| is returned. This can be the case if the user

requested a "weak" attach and we haven't received an event that would cause us to load symbols

yet, or we're still waiting on the response to `GetModules` from the backend.

In certain cases, such as when running as part of a script or tests that run many operations

faster than a user would normally type them, or when downloading large symbol files, this

function may return |kInProgress|. Callers should use that signal to register a post-download

task with the System object.

If there are any symbols that are not loaded and there are no pending indexing operations or

downloads, this function returns |kNotLoaded|. Note that just one module missing symbols would

trigger this return value, and some operations that do not depend on that particular module's

symbols could still work.

Queries the process for the currently-loaded modules (this always recomputes the list). The

force_reload_symbols flag will force-reload all symbol information for all modules, regardless

of whether it may already have symbols.

Queries the process for its address map if |address| is zero the entire map is requested. If

|address| is non-zero only the containing region if exists will be retrieved.

Returns all threads in the process. This is as of the last update from the system. If the

program is currently running, the actual threads may be different since it can be

asynchronously creating and destroying them.

Some programs also change thread names dynamically, so the names may be stale. Call

SyncThreads() to update the thread list with the debuggee.

The pointers will only be valid until you return to the message loop.

Returns the thread in this process associated with the given koid.

Asynchronously refreshes the thread list from the debugged process. This will ensure the thread

names are up-to-date, and is also used after attaching when there are no thread notifications

for existing threads.

If the Process is destroyed before the call completes, the callback will not be issued. If this

poses a problem in the future, we can add an error code to the callback, but will need to be

careful to make clear the Process object is not valid at that point (callers may want to use it

to format error messages).

To get the computed threads, call GetThreads() once the callback runs.

Pauses (suspends in Zircon terms) all threads in the process, it does not affect other

processes.

The backend will try to ensure the threads are actually paused before issuing the on_paused

callback. But this is best effort and not guaranteed: both because there's a timeout for the

synchronous suspending and because a different continue message could race with the reply.

Applies to all threads in the process.

See Thread::Continue() for more detail on the forwarding of exceptions.

The callback does NOT mean the step has completed, but rather the setup for the function was

successful. Symbols and breakpoint setup can cause asynchronous failures.

Stops all thread controllers which may be doing automatic stepping for all threads in the

process. See Thread::CancelAllThreadControllers() for more.

Returns the SymbolDataProvider that can be used to evaluate symbols in the context of this

process. This will not have any frame information so the available operations will be limited.

If the caller has a Frame, prefer Frame::GetSymbolDataProvider() which does have access to

registers and other frame data.

Get the TLS helper code for this process. These are memory blobs containing DWARF programs

which we can run to evaluate thread-local addresses. The callback is issued synchronously if

the data is available.

Reads memory from the debugged process.

Write memory to the debugged process.

Executes zx_object_get_info with ZX_INFO_HANDLE_TABLE for the process and gives the result

back.

Documents how this process was started.

This is useful for user feedback.

The kind of process being debugged. Most processes will be |kNormal| but certain things, like

tests, want slightly different actions to be taken slightly differently. For example, different

test frameworks have different ways of raising test failures to the debugger, which surface as

different exception types, and vary across test frameworks, runtimes, and architectures.

Despite these differences, we pretty much always want things like "continue" to behave the same

across them all.

It is up to the upper layers to determine when a particular process is non-standard and update

the process objects accordingly.

This enum represents the possible states of loading symbols for a particular module in a

particular process. The transition edges are as follows:

kNone -> kNoModules: When a Process object has been created. Simply creating a

Process object does not imply that it will send a `GetModules`

request (that depends on the attach method).

kNoModules -> kLoaded: When `GetModules` returns and symbols are loaded synchronously.

kNoModules -> kInProgress: When symbols are not found locally and need to be downloaded

after a `GetModules` call.

kInProgress -> kNotLoaded: When the symbols aren't found on any symbol servers or indexing

failed.