|
Call-back function to handle breakpoint set requests from a debugger. Once a callback accepted control over a breakpoint at the given address, Pin and PinADX will not stop at that address. The stop responsibility is handled solely by the tool. However, PinADX does keep track of the breakpoint, in case the tool wants to "reset" the breakpoint and give the control back to PinADX.
|
|
Call-back function to handle commands from a debugger. The format of the cmd and reply strings may vary depending on which debugger is connected to Pin. Tools can call PIN_GetDebuggerType() to tell which debugger is connected. When the debugger is GDB, cmd is the text string that the user types after the "monitor" command and reply is displayed verbatim as a response to the command. Pin reserves all command strings that start with the prefix "pin " or "pin:". Pin interprets these commands itself and does not pass them on to the tool.
|
|
Possible connection types for an application debugger. The connection type can be specified either via the -appdebug knobs or by PIN_SetDebugMode(). |
|
Options which affect application debugging.
|
|
|
Application debugger types that could be connected to Pin. |
|
Register a handler that can intercept breakpoint set/delete commands sent from an application debugger. This API allows a tool to take control over specific breakpoints stop behavior. A tool may install more than one handler function. Pin calls each one until it reaches an handler that understand the command.
|
|
Register a handler that can interpret commands sent from an application debugger. This API allows a tool to extend the normal set of commands understood by a debugger that is connected to Pin. A tool may install more than one interpreter function. Pin calls each one until it reaches an interpreter that understand the command.
|
|
A tool can call this API to stop execution in an application debugger as though a breakpoint was hit. The ctxt parameter tells the register state that the debugger sees when the application stops. If application level debugging is not enabled in this Pin session, execution does not stop, but resumes immediately at ctxt. Tools can tell if application level debugging is enabled by calling PIN_GetDebugStatus(). The semantics of this API are very similar to PIN_ExecuteAt(). Both APIs abandon the current analysis function and resume execution at a new CONTEXT. The only difference is that PIN_ApplicationBreakpoint() also stops at a breakpoint in the application debugger. This API can be called from an analysis function or a replacement routine, but not from a callback. The expected format of the msg string may depend on which debugger is connected to Pin. Tools can call PIN_GetDebuggerType() to find the debugger type. When used with GDB, the msg string is displayed verbatim to the user when the debugger stops. The debugger adds a newline to the end of the string before displaying it.
|
|
If the given stopped thread has a pending tool breakpoint, this function can change the message associated with that breakpoint request or it can squash the breakpoint request entirely. The debugger will see the effect of the changed breakpoint after it resumes execution of the thread. If the tool changes the breakpoint message, the debugger will receive the breakpoint event with the new message. If the tool squashes the breakpoint request, the thread will not stop at the breakpoint at all. Instead, it continues executing at the ctxt parameter that was passed to PIN_ApplicationBreakpoint().
|
|
This function retrieves the information that an application level debugger will need in order to connect to this Pin session.
|
|
This function tells the type of application level debugger (if any) that is connected to Pin. If no debugger is connected, returns DEBUGGER_TYPE_UNKNOWN.
|
|
This function tells whether application level debugging is enabled in this Pin session. If so, it tells whether an application debugger is currently connected to Pin.
|
|
Tells whether a stopped thread has called PIN_ApplicationBreakpoint(), but the breakpoint has NOT yet been reported to the debugger. For example, this can occur if two threads call PIN_ApplicationBreakpoint() simultaneously and the debugger has asked Pin to report one debugger event at a time. In this case, Pin reports one breakpoint to the debugger and leaves the other breakpoint pending.
|
|
Remove a previously installed breakpoint handler function.
|
|
Remove a previously installed debug interpreter function.
|
|
Resets the breakpoint address, and returns the control back to PinADX.
|
|
Set whether application debugging is enabled or disabled in this Pin session and set the debugging mode if debugging is enabled. This API overrides the following knobs if they are specified on the command line:
If the tool calls this API, it must be called before PIN_StartProgram().
|
|
Waits for an application level debugger to connect to this Pin session. This function may only be called after PIN_StartProgram(). If the debugger status is DEBUG_STATUS_DISABLED or DEBUG_STATUS_UNCONNECTABLE, it returns FALSE immediately. After a successful return, an application level debugger is connected to Pin. The debugger will stop the application soon, but there is no guarantee that this will happen immediately after this API returns. If the tool wants to guarantee an immediate stop, it should call PIN_ApplicationBreakpoint().
|