Difference between revisions of "CDT/Obsolete/MultiCoreDebugWorkingGroup/UseCases"

Revision as of 11:37, 23 November 2010

Multi-core debugging use cases

• 1) Programs with multiple threads

  1.1) Two or more threads interacting : User is debugging a program with multiple threads which are interacting with each other.

  1.1.1) Debugging threads which contend for the same lock. :

  1. When a thread blocks while stepping,
  2. User switches focus to another thread and steps until the lock is released,
  3. User switches focus back to the first thread and continues debugging.

  1.1.2) Debugging race conditions where multiple threads are reading and writing some shared data :

  1. User sets a breakpoint at a location where a shared variable is written.
  2. Multiple threads hit the breakpoint
  3. User looks at each threads to see the thread-private data in each thread.
  4. User steps the threads individually to watch what happens to the shared data.
  5. Alternatively, user steps all threads.
  6. Multiple threads may hit the breakpoint at the same time.
  7. User sets another breakpoint further down in routines that access the shared data.
  8. Halt execution when another thread accesses shared address.
  9. User continues some or all of the threads which stopped at the first breakpoint so that they may reach the second breakpoint.

  1.2) Debugging a subset of threads : User is debugging a program with multiple threads, but he is interested only in interacting with some of the threads.

  1.2.1) User debugs with breakpoints restricted to a sub-set of threads.

  1. User creates a breakpoint on the routine to be debugged.
  2. User defines which threads should be allowed to hit the breakpoint.
  3. The threads hit the breakpoint and user steps through them.

  1.2.2) Run control for a subset of threads : User repeatedly suspends and resumes a subset of threads.

  1.2.3) Terminating/re-launching :

  1. User debugs a subset of threads (using filtered breakpoints, etc.).
  2. User terminates and relaunches a process, and continues to debug the same set of threads.

  1.2.4) Tasks submitted to a thread pool : User is debugging a routine which may be executed by any thread in a thread pool at any time, and by some threads in the thread pool at the same time.

  1. User sets a breakpoint and a number of threads hit the breakpoint, user examines the data and resumes threads individually.
  2. User sets a conditional breakpoint where the condition is used to identify a specific tasks. For example, an instance of an update object when debugging flexible hierarchy views.

  1.3) Program with large number (100+) of threads : User is debugging programs with large numbers of threads and he needs to manage those threads effectively.

  1.3.1) User needs to switch between suspended threads

  1. User sets a breakpoint that some threads may hit.
  2. Some threads hit the breakpoint.
  3. User switches focus between suspended threads to control them and examine their data.

  1.3.2) Threads created/destroyed rapidly: User is debugging a process with threads being created and destroyed at a rapid rate (more than 1 thread/sec.)

  1.4) Context-specific expressions  : User is using the expressions view to monitor different expressions which are valid only in specific context.

  1.4.1) Local variable expressions : User creates expressions for local variables in a specific function. These variables are not valid in any other context.

  1.4.2) Thread-local variable expressions : User creates expressions for variables which are valid only in specific threads.

  1.5) Clone threads : Debugging a system where multiple threads are executing the same section of code.

  1.5.1) Comparing data in clone threads : User compares variables in threads which are stopped in the same section of code.

• 2) Multiple processes that interact with each other

  2.1) Launching multiple processes at the same time : When starting a debug session, user creates multiple processes and debugs them.

  2.2) Attaching to multiple processes : Instead of launching, user attaches to multiple processes and debugs them simultaneously.

  2.3) Debugging a process that forks : User is debugging a process that forks. After the fork user debugs both processes.

  2.4) View where users can see the cores and what is running on each core, in many cases users will use core affinity to put thread on specific core for execution locality. The threads don't move much between cores.

  2.5) Define what are the process/threads for an application, attach to all of them;

  2.6) Select one core and stop it or put a breakpoint on all the threads running on it; or a global breakpoint for the first process or thread hitting the breakpoint;

  2.7) Continue/step for all thread running on a core;

  2.8) Understand the interaction between process/threads of different cores, e.g. signal breakpoint;

  2.9) A few use cases/features are almost the same as the one in PTP (process set, operations on set, etc.) http://www.eclipse.org/ptp/documentation/2.1/org.eclipse.ptp.help/html/06parDebugging.html

• 3) Systems with multiple cores (On Chip Debugging)

  3.1) Hardware bring-up debugging : User attaches a debugger to a multi-core system for purpose of hardware configuration, such as configuring registers, IO devices, etc. (no OS, no symbol data, no executable image)

  3.2) No-OS debugging : User attaches to a multi-core system and downloads simple executable image to each core and debugs them.

  3.3) Debugging with OS-awareness : User attaches to a multi-core system, downloads an OS image to each, starts debugging the entire OS on each board, or specific tasks/processes running on specific cores.

  3.4) Synchronized run control operations : Some multi-core debuggers allow for performing synchronized operations on multiple cores. Allowing the debugger or the hardware to operate on multiple cores minimizes the skid, or the time lag, in when the operations are carried out on the different cores. There needs to be dedicated UI and APIs to exercise these debugger features.