A method for debugging a processor which is executing vertices of a software application is described. Each vertex is assigned to a programming thread of the processor. The processor has debug hardware for raising exceptions in certain break conditions. The method comprises inspecting a vertex identifier, comparing the vertex identifier and raising an instruction exception event for the programming thread if the vertex identifier assigned to the thread matches the vertex break identifier in the debug hardware. Exceptions are raised based on identified vertices, rather than just individual instructions or instruction addresses.

This document describes debugging multiple instances of code by detecting a variance in thread patterns of threads of execution relative to the multiple instances of executing code. A first instance of the code is executed and a first thread pattern is identified indicative of a first plurality of threads of execution of the first instance of the code. A second instance of the code is executed, the second instance of the code beginning executing prior to the first instance of the code completing executing, and a second thread pattern is identified indicative of a second plurality of threads of execution of the second instance of the code. A comparative representation of the first thread pattern and the second thread pattern is generated relative to each other. A variance between the first thread pattern and the second thread pattern relative to the comparative representation is identified, the variance typically being indicative of a bug in the code.

A real-time debugger implementation maintains and manages multiple debug contexts allowing developers to interact with real-time applications without “breaking” the system in which the debug application is executing. The debugger allows multiple debug contexts to exist and allows break points in real-time and non-real-time code portions of one or more applications executing on a debug enabled core of a processor. A debug monitor function may be implemented as a hardware logic module on the same integrated circuit as the processor. Higher priority interrupt service requests may be serviced while otherwise maintaining a context for the debug session (e.g., stopped at a developer defined breakpoint). Accordingly, the application developer executing the debugger may not have to be concerned with processing occurring on the processor that may be unrelated to the current debug session.

A testing tool includes a clock generation circuit generating a test clock and outputting the test clock via a test clock output pad, data processing circuitry clocked by the test clock, and data output circuitry receiving data output from the data processing circuitry and outputting the data via an input/output (IO) pad, the data output circuitry being clocked by the test clock. The testing tool also includes a programmable delay circuit generating a delayed version of the test clock, and data input circuitry receiving data input via the IO pad, the data input circuitry clocked by the delayed version of the test clock. The delayed version of the test clock is delayed to compensate for delay between transmission of a pulse of the test clock via the test clock output pad to an external computer and receipt of the data input from the external computer via the IO pad.

A real-time debugger implementation maintains and manages multiple debug contexts allowing developers to interact with real-time applications without “breaking” the system in which the debug application is executing. The debugger allows multiple debug contexts to exist and allows break points in real-time and non-real-time code portions of one or more applications executing on a debug enabled core of a processor. A debug monitor function may be implemented as a hardware logic module on the same integrated circuit as the processor. Higher priority interrupt service requests may be serviced while otherwise maintaining a context for the debug session (e.g., stopped at a developer defined breakpoint). Accordingly, the application developer executing the debugger may not have to be concerned with processing occurring on the processor that may be unrelated to the current debug session.

A real-time debugger implementation maintains and manages multiple debug contexts allowing developers to interact with real-time applications without “breaking” the system in which the debug application is executing. The debugger allows multiple debug contexts to exist and allows break points in real-time and non-real-time code portions of one or more applications executing on a debug enabled core of a processor. A debug monitor function may be implemented as a hardware logic module on the same integrated circuit as the processor. Higher priority interrupt service requests may be serviced while otherwise maintaining a context for the debug session (e.g., stopped at a developer defined breakpoint). Accordingly, the application developer executing the debugger may not have to be concerned with processing occurring on the processor that may be unrelated to the current debug session.

Diffing subject and comparison traces. A first call tree representing function calls made by a first executable entity is created based on subject trace, and a second call tree representing function calls made by a second executable entity is created based on a comparison trace. A differencing tree is created from the call trees, with differencing tree nodes indicate a differencing status between the first and second call trees. A differencing cost is assigned to each differencing tree node, based at least on the nodes' differencing status. A differencing tree node is identified based on following nodes that most contribute to differences between the first and second call trees, and it is used to provide an indicia of a difference between the first and second function calls.

A deterministic replay of a multi-threaded trace on a multi-threaded processor is described. An example of a computer-readable storage medium includes instructions to cause at least one processor to receive graphics processing unit (GPU) program code for tracing, the program code including a plurality of instructions; analyze the plurality of instructions to identify instructions of the program code that are events requiring synchronization; instrument each of the identified events to generate instrumented program code; execute the instrumented program code on a plurality of hardware threads of the GPU to generate trace data; and emulate the trace data utilizing an emulator on a plurality of hardware traces of a central processing unit (CPU), including replaying the identified events according to an order of occurrence of the identified events.

A computer program product for testing a server code in a server concurrently handling multiple client requests includes creating a job-specific breakpoint in the server code using a library application programming interface, the job-specific breakpoint in the server code is enabled or disabled based on a job identifier, the library application programming interface controls the job-specific breakpoint in the server code and includes an application programming interface for establishing a new server connection with the server and retrieving the job identifier from the server associated with the established new server connection, pausing execution of a client job based on enabling the job-specific breakpoint in the server code using the library application programming interface, and resuming execution of the client job based on disabling the job-specific breakpoint in the server code using the library application programming interface.

Data race detection in multi-threaded programs can be achieved by leveraging per-thread memory protection technology in conjunction with a custom dynamic memory allocator to protect shared memory objects with unique memory protection keys, allowing data races to be turned into inter-thread memory access violations. In various embodiments, threads acquire or release the keys used for accessing protected memory objects at the entry and exit points of critical sections within the program. An attempt by a thread to access a protected memory object within a critical section without the associated key triggers a protection fault, which may be indicative of a data race.