Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

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

(Multi-core debugging use cases)
Line 1: Line 1:
 
== Multi-core debugging use cases ==
 
== 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. :
 
*::# When a thread blocks while stepping,
 
*::# User switches focus to another thread and steps until the lock is released,
 
*::# 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 :
 
*::# User sets a breakpoint at a location where a shared variable is written. 
 
*::# Multiple threads hit the breakpoint
 
*::# User looks at each threads to see the thread-private data in each thread.
 
*::# User steps the threads individually to watch what happens to the shared data. 
 
*::# Alternatively, user steps all threads.
 
*::# Multiple threads may hit the breakpoint at the same time. 
 
*::# User sets another breakpoint further down in routines that access the shared data.
 
*::# Halt execution when another thread accesses shared address.
 
*::# 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. 
 
*::# User creates a breakpoint on the routine to be debugged.
 
*::# User defines which threads should be allowed to hit the breakpoint.
 
*::# 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 :
 
*::# User debugs a subset of threads (using filtered breakpoints, etc.). 
 
*::# 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.
 
*::# User sets a breakpoint and a number of threads hit the breakpoint, user examines the data and resumes threads individually.
 
*::# 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
 
*::# User sets a breakpoint that some threads may hit.
 
*::# Some threads hit the breakpoint.
 
*::# 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.
 
 
  
 
* '''3) Systems with multiple cores (On Chip Debugging)'''
 
* '''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.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.2) No-OS debugging : User attaches to a multi-core system and downloads simple executable image to each core and debugs them.

Revision as of 13:58, 23 November 2010

Multi-core debugging use cases

  • 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.

Back to the top