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/Archive/cdt-debug-dsf-gdb"

< CDT‎ | Archive
(Version support)
(Launching)
Line 19: Line 19:
 
* GDB Debugger options
 
* GDB Debugger options
 
** Non-stop mode selection
 
** Non-stop mode selection
 +
** Reverse debugging mode selection
  
 
=== CDT Breakpoints Support ===
 
=== CDT Breakpoints Support ===

Revision as of 13:59, 4 May 2009

Contents

Overview

Source

Source plugins and features are located in CVS at /cvsroot/tools/org.eclipse.cdt/dsf-gdb.

Features

Version support

  • Run the JUnit tests with GDB 6.6
  • Run the JUnit tests with GDB 6.7
  • Run the JUnit tests with GDB 6.8

Launching

N&N Entry

  • Launch Configurations
    • Launch an application on local host
    • Attach to a running process
    • Launch an application on a remote host
  • GDB Debugger options
    • Non-stop mode selection
    • Reverse debugging mode selection

CDT Breakpoints Support

N&N Entry

Non-stop mode multi-threaded debugging support

N&N Entry

Multi-process Debugging

N&N Entry

CLI Console

N&N Entry

Manual Test Procedures

GDB Basic Sanity Test

    1. Check out and build the sanity test project from /cvsroot/dsdp/org.eclipse.dd.dsf/tests/SanityTest
    2. Launch the DSF debugger with break at main
    3. Follow instructions in the test.

Launching

  • Perspective
    1. In Preferences->Run/Debug->Perspectives, make sure that at least one perspective change option is set to prompt.
    2. Set the java or c++ perspective
    3. Launch a DSF program
      • Verify that there is a prompt to switch perspective to Debug, Answer yes
      • Verify the perspective switches
  • Expanding after launch
      • Verify from the above test that the Debug view has a selection to the top-most thread
    1. Close Debug view
    2. Open Debug view
    3. Verify that the Debug view has a selection to the top-most thread
  • Break on main
    1. Set a valid break-on-main symbol, and launch.
      • Check: the program breaks at the correct location.
    2. Set an invalid break-on-main symbol, and launch.
      • Check: the launch should fail with an error from creating the break-on-main breakpoint
    3. Set a break-on-main symbol that is not reachable by the program, but the program continues running, and launch.
      • Check: the launch should complete as if there was no break-on-main symbol set.
    4. Set a break-on-main symbol that is not reachable by the program, but and the program exits quickly.
      • Check: the launch should complete and the program should run and terminate normally.
  • Remote Launch
    1. Start a gdbserver session with the binary of the eclipse C++ project
    2. Use the DSF Remote launch to connect to that gdbserver
      • Verify that the debugging session is the same as a local debugging session
      • Verify that the Restart button is grayed out
  • Local Attach Launch
    1. Start the binary of your project outside of eclipse (this binary should take a long time to execute to give you enough time to attach to it)
    2. Use the DSF Attach to Local applicaiton launch
      • Verify that a popup window prompts for the process to attach to
    3. Select the binary you started
      • Verify that the debugging session is the same as a local debugging session
      • Verify that the Restart button is grayed out
      • Verify that the output of the binary remains on the terminal where it was started
  • Remote Attach Launch
    1. Start a gdbserver session with the --multi flag and no binary
    2. Start the binary of your project outside of eclipse (this binary should take a long time to execute to give you enough time to attach to it)
    3. Use the DSF Attach launch to connect to that gdbserver using the 'gdbserver Debugger' type
      • Verify that a popup window prompts for the process pid to attach to (no list)
      • Put in the pid of the binary you started
      • Verify that the debugging session is the same as a local debugging session
      • Verify that the Restart button is grayed out
      • Verify that the output of the binary remains on the terminal where it was started
  • Output
    1. Launch a local debug session
    2. Step the program to execute a couple of instructions that have a printf
      • Verify that the output of the program is properly seen in a separate console.
  • Restart
    1. Launch a local debug session
    2. Step the program to execute a couple of instructions
    3. Press the Restart button and verify that the program restarts from the beginning
      • Verify also that the "Break on main option is still respected on the restart
      • Verify also that the output of the program is properly seen in a separate console.

Line Breakpoints (General)

Test Setup

  1. To avoid stack overflow, set memory to 512M
    1. In the launch configuration, Arguments tab, VM arguments section: -Xmx512M
  2. To ensure integrity between the UI and the back-end, all verifications (Check:) are performed from 3 points:
    1. Back-end activities with GDB/MI traces
    2. Back-end breakpoint status with "info break" at the console
    3. Platform breakpoint status in Breakpoint View (with Breakpoint Properties)
  3. Launch the Eclipse workbench
  4. Start a DSF debug session (DsfBreakpoints)

Test 1: Breakpoint setting

    1. In the editor, add a new line breakpoint (BP-1)
      • Check: A new breakpoint is inserted and it is enabled
    2. In the view menu: enable the "Show Full Paths" check box
      • Check: The breakpoint full path is displayed in the view
    3. In the editor, disable the "Show Full Paths" check box
      • Check: The breakpoint full path is not displayed in the view

Test 2: Breakpoint activation

    1. In the editor, disable BP-1
      • Check: BP-1 is disabled
    2. In the editor, enable BP-1
      • Check: BP-1 is enabled
    3. From the breakpoint context menu, disable BP-1
      • Check: BP-1 is disabled
    4. From the breakpoint context menu, enable BP-1
      • Check: BP-1 is enabled

Test 3: Breakpoint condition

    1. Set an invalid condition on BP-1
      • Check: The update is rejected and BP-1 is not changed
    2. Set a valid condition on BP-1
      • Check: The update is accepted and BP-1 has the new condition
    3. Set an invalid condition on BP-1
      • Check: The update is rejected and BP-1 kept the valid condition
    4. Clear the BP-1 condition
      • Check: The update is accepted and BP-1 no longer has a condition

Test 4: Breakpoint ignore count

    1. Set an ignore count on BP-1
      • Check: The update is accepted and BP-1 has the new ignore count
    2. Reset an ignore count on BP-1 (set to 0)
      • Check: The update is accepted and BP-1 has no ignore count
  • Test 5: Breakpoint deletion (simple)
    1. From the GUI, delete BP-1
      • Check: BP-1 is removed

Test 6: Breakpoint persistence

    1. Create 4 breakpoints with the following characteristics:
      1. BP-1: enabled, no condition, no ignore count
      2. BP-2: disabled, with condition, no ignore count
      3. BP-3: disabled, no condition, with ignore count
      4. BP-4: enabled, with condition, with ignore count
    2. Check: The 4 breakpoints are correctly created
    3. Terminate the debugging session
    4. Start a new debugging session
      • Check: The 4 breakpoints are correctly restored
    5. Terminate the debugging session
    6. Enable all breakpoints
    7. Start a new debugging session
      • Check: The 4 breakpoints are correctly restored (and enabled)

Test 7: Import/export breakpoints to file

    1. Create 4 breakpoints with the following characteristics (re-use the ones from previous step):
      1. BP-1: enabled, no condition, no ignore count
      2. BP-2: disabled, with condition, no ignore count
      3. BP-3: disabled, no condition, with ignore count
      4. BP-4: enabled, with condition, with ignore count
      • Check: The 4 breakpoints are correctly created
    2. Export the 4 breakpoints to file
      • Check: The breakpoints file is created
    3. Remove all breakpoints
      • Check: The 4 breakpoints are removed
    4. Import the breakpoint file
      • Check: The 4 breakpoints are correctly restored
    5. Remove all breakpoints
    6. Terminate the debugging session
    7. Start a new debugging session
      • Check: No breakpoint is installed
    8. Import the breakpoint file
      • Check: The 4 breakpoints are correctly restored

Test 8: Breakpoint deletion (multiple)

    1. From the GUI, delete BP-1, BP-2, BP-3 and BP-4
      • Check: the 4 breakpoints are removed

Watchpoints (General)

Test Setup

  1. To avoid stack overflow, set memory to 512M
    1. In the launch configuration, Arguments tab, VM arguments section: -Xmx512M
  2. To ensure integrity between the UI and the back-end, all verifications (Check:) are performed from 3 points:
    1. Back-end activities with GDB/MI traces
    2. Back-end breakpoint status with "info break" at the console
    3. Platform breakpoint status in Breakpoint View (with Breakpoint Properties)
  3. Launch the Eclipse workbench
  4. Start a DSF debug session (DsfBreakpoints)

Test 1: Watchpoint setting

    1. In the Breakpoint View, add a new watchpoint (WP-1)
      • Check: A new watchpoint is inserted and it is enabled

Test 2: Watchpoint activation

    1. From the watchpoint context menu. disable WP-1
      • Check: WP-1 is disabled
    2. From the watchpoint context menu, enable WP-1
      • Check: WP-1 is enabled

Test 3: Watchpoint condition

    1. Set an invalid condition on WP-1
      • Check: The update is rejected and WP-1 is not changed
    2. Set a valid condition on WP-1
      • Check: The update is accepted and WP-1 has the new condition
    3. Set an invalid condition on WP-1
      • Check: The update is rejected and WP-1 kept the valid condition
    4. Clear the WP-1 condition
      • Check: The update is accepted and WP-1 no longer has a condition

Test 4: Watchpoint ignore count

    1. Set an ignore count on WP-1
      • Check: The update is accepted and WP-1 has the new ignore count
    2. Reset an ignore count on WP-1 (set to 0)
      • Check: The update is accepted and WP-1 has no ignore count

Test 5: Watchpoint deletion (simple)

    1. From the GUI, delete WP-1
      • Check: WP-1 is removed

Test 6: Watchpoint persistence

    1. Create 4 watchpoints with the following characteristics:
      1. WP-1 enabled, write, no condition, no ignore count
      2. WP-2 disabled, read, with condition, no ignore count
      3. WP-3 disabled, read/write, no condition, with ignore count
      4. WP-4 enabled, write, with condition, with ignore count
      • Check: The 4 watchpoints are correctly created
    2. Terminate the debugging session
    3. Start a new debugging session
      • Check: The 4 watchpoints are correctly restored
    4. Terminate the debugging session
    5. Enable all watchpoints
    6. Start a new debugging session
      • Check: The 4 watchpoints are correctly restored (and enabled)

Test 7: Import/export watchpoints to file

    1. Create 4 watchpoints with the following characteristics (re-use watchpoints from previous step):
      1. WP-1 enabled, write, no condition, no ignore count
      2. WP-2 disabled, read, with condition, no ignore count
      3. WP-3 disabled, read/write, no condition, with ignore count
      4. WP-4 enabled, write, with condition, with ignore count
      • Check: The 4 watchpoints are correctly created
    2. Export the 4 watchpoints to file
      • Check: The watchpoints file is created
    3. Remove all watchpoints
      • Check: The 4 watchpoints are removed
    4. Import the watchpoints file
      • Check: The 4 watchpoints are correctly restored
    5. Remove all watchpoints
    6. Terminate the debugging session
    7. Start a new debugging session
      • Check: No watchpoints is installed
    8. Import the watchpoints file
      • Check: The 4 watchpoints are correctly restored

Test 8: Watchpoint deletion (multiple)

    1. From the GUI, delete WP-1, WP-2, WP-3 and WP-4
      • Check: The 4 watchpoints are removed

Skip All (Breakpoints) Button

Test Setup

  1. To avoid stack overflow, set memory to 512M
    1. In the launch configuration, Arguments tab, VM arguments section: -Xmx512M
  1. To ensure integrity between the UI and the back-end, all verifications (Check:) are performed from 3 points:
    1. Back-end activities with GDB/MI traces
    2. Back-end breakpoint status with "info break" at the console
    3. Platform breakpoint status in Breakpoint View (with Breakpoint Properties)
  2. Launch the Eclipse workbench
  3. Create 3 line breakpoints (anything will do)
  4. Start a DSF debug session (DsfBreakpoints)
    • Check: Breakpoints are created and enabled

Test 1: Simple ON/OFF

    1. Toggle the 'Skip All Button' SAB to ON
      • Check: BPs 1, 2, 3 are disabled
    2. Toggle the SAB to OFF
      • Check: BPs 1, 2, 3 are enabled

Test 2: ON/OFF with some disabled BPs

    1. Disable BP 2
      • Check: Only BP-2 is disabled
    2. Toggle the SAB to ON
      • Check: All breakpoints are disabled
    3. Toggle the SAB to OFF
      • Check: BPs 1, 3 are enabled
    4. Disable BP 1 and 3
    5. Enable BP 2
      • Check: Only BP-2 is enabled
    6. Toggle the SAB to ON
      • Check: All breakpoints are disabled
    7. Toggle the SAB to OFF
      • Check: Only BP-2 is enabled

Test 3: ON/OFF with all BPs disabled

    1. Disable BPs 1, 2, 3
    2. Toggle the SAB to ON
      • Check: Nothing happens
    3. Toggle the SAB to OFF
      • Check: Nothing happens

Test 4: Change BPs state while OFF

    1. Enable BP 2
    2. Disable BPs 1, 3
    3. Toggle the SAB to ON
      • Check: BP 2 is disabled
    4. Enable BP 1
      • Check: Nothing happens
    5. Disable BP 2
      • Check: Nothing happens
    6. Toggle the SAB to OFF
      • Check: BP 1 is enabled

Test 6: Startup

    1. Terminate DSF debug session
    2. Enable BPs 1, 2, 3
    3. Toggle the SAB to ON
    4. Start DSF debug session
      • Check: BPs 1, 2, 3 are created and disabled
    5. Toggle the SAB to OFF
      • Check: BPs 1, 2, 3 are enabled

Breakpoint Thread Filters

Test Setup

  1. To avoid stack overflow, set memory to 512M
    1. In the launch configuration, Arguments tab, VM arguments section: -Xmx512M
  2. To ensure integrity between the UI and the back-end, all verifications (Check:) are performed from 3 points:
    1. Back-end activities with GDB/MI traces
    2. Back-end breakpoint status with "info break" at the console
    3. Platform breakpoint status in Breakpoint View (with Breakpoint Properties)
  3. Launch the Eclipse workbench
    1. Create a breakpoint on the return statement of the printMsg function ("return NULL")
    2. Start a DSF debug session (DsfThreads)
      • Check: Breakpoint is created and enabled
    3. Run to breakpoint
      • Check: There are 3 threads (1, 2 and 3) in the Debug View

Test 1: Filter out a thread

    1. Set filter for threads 1, 2
      • Check: The original breakpoint is removed
      • Check: 2 identical breakpoints are installed, one for each thread selected

Test 2: Filtered thread substitution

    1. Change filter for threads 1, 3
      • Check: The breakpoint for thread 2 is removed
      • Check: 2 identical breakpoints are installed, one for each thread selected

Test 3: Remove a filtered thread

    1. Change filter for thread 2 only
      • Check: The breakpoints for threads 1, 3 are removed
      • Check: A breakpoint is installed for thread 2

Test 4: Add a filtered thread

    1. Change filter for thread 2, 3
      • Check: 2 identical breakpoints are installed, one for each thread selected

Test 5: Remove thread filters

    1. Remove filter
      • Check: The breakpoints for threads 2, 3 are removed
      • Check: A new breakpoint is set with no thread filter

Test 6: Initial state propagation

    1. Add a valid condition and ignore count to the breakpoint
      • Check: The breakpoint is updated
    2. Add filter for threads 1, 2
      • Check: The original breakpoint is removed
      • Check: 2 new breakpoints are set with the correct condition, ignore count, one for each thread selected

Test 7: Invalid condition propagation

    1. Change to an invalid condition
      • Check: Updates failed
      • Check: Breakpoints aren't changed (previous valid condition is kept)

Test 8: Valid condition propagation

    1. Add a valid condition
      • Check: Condition is properly set for both breakpoints

Test 9: Condition/Ignore count removal propagation

    1. Remove condition and ignore count
      • Check: Condition and ignore count are removed from both breakpoints

Test 10: State persistence

    1. Add a valid condition, ignore count
      • Check: Condition/Ignore count are properly set for both breakpoints
    2. Remove thread filter
      • Check: The breakpoints for threads 1, 2 are removed
      • Check: A new breakpoint is set with the correct condition, ignore count and no thread filter

Test 11: Simultaneous update of state and thread filter

    1. Add filter for threads 1, 2, a valid condition and an ignore count
      • Check: The original breakpoint is removed
      • Check: 2 new breakpoints are set with proper ignore count, condition
    2. Remove thread filter
      • Check: The breakpoints for threads 1, 2 are removed
      • Check: A new breakpoint is set with the correct condition, ignore count and no thread filter

Test 12: Addition of thread filter, invalid condition and ignore count

    1. Add filter for threads 1, 2, invalid condition, ignore count
      • Check: The original breakpoint is removed
      • Check: 2 new breakpoints are set with proper ignore count and old (valid) condition
    2. Remove thread filter
      • Check: The breakpoints for threads 1, 2 are removed
      • Check: A new breakpoint is set with the correct condition, ignore count and no thread filter

Test 13: Enable, disable breakpoints

    1. Disable the breakpoint
      • Check: The breakpoint is disabled
    2. Add filter for threads 1, 2
      • Check: The original breakpoint is removed
      • Check: 2 new disabled breakpoints are set with proper ignore count, condition
    3. Enable the breakpoint
      • Check: Both back-end breakpoints are enabled
    4. Remove thread filter
      • Check: The breakpoints for threads 1, 2 are removed
      • Check: A new (enabled) breakpoint is set with the correct condition, ignore count and no thread filter

Back to the top