Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
CDT/Archive/cdt-debug-dsf-gdb
Contents
- 1 Overview
- 2 Features
- 3 Manual Test Procedures
- 3.1 GDB Basic Sanity Test
- 3.2 Launching
- 3.3 Line Breakpoints (General)
- 3.4 Watchpoints (General)
- 3.4.1 Test Setup
- 3.4.2 Test 1: Watchpoint setting
- 3.4.3 Test 2: Watchpoint activation
- 3.4.4 Test 3: Watchpoint condition
- 3.4.5 Test 4: Watchpoint ignore count
- 3.4.6 Test 5: Watchpoint deletion (simple)
- 3.4.7 Test 6: Watchpoint persistence
- 3.4.8 Test 7: Import/export watchpoints to file
- 3.4.9 Test 8: Watchpoint deletion (multiple)
- 3.5 Skip All (Breakpoints) Button
Overview
Features
Version support
- GDB 6.7+
Launching
- 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
Non-stop mode multi-threaded debugging support
Multi-process Debugging
CLI Console
Manual Test Procedures
GDB Basic Sanity Test
- Check out and build the sanity test project from /cvsroot/dsdp/org.eclipse.dd.dsf/tests/SanityTest
- Launch the DSF debugger with break at main
- Follow instructions in the test.
Launching
- Perspective
- In Preferences->Run/Debug->Perspectives, make sure that at least one perspective change option is set to prompt.
- Set the java or c++ perspective
- 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
- Close Debug view
- Open Debug view
- Verify that the Debug view has a selection to the top-most thread
- Break on main
- Set a valid break-on-main symbol, and launch.
- Check: the program breaks at the correct location.
- Set an invalid break-on-main symbol, and launch.
- Check: the launch should fail with an error from creating the break-on-main breakpoint
- 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.
- 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.
- Set a valid break-on-main symbol, and launch.
- Remote Launch
- Start a gdbserver session with the binary of the eclipse C++ project
- 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
- 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)
- Use the DSF Attach to Local applicaiton launch
- Verify that a popup window prompts for the process to attach to
- 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
- Start a gdbserver session with the --multi flag and no binary
- 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)
- 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
- Launch a local debug session
- 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
- Launch a local debug session
- Step the program to execute a couple of instructions
- 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
- To avoid stack overflow, set memory to 512M
- In the launch configuration, Arguments tab, VM arguments section: -Xmx512M
- To ensure integrity between the UI and the back-end, all verifications (Check:) are performed from 3 points:
- Back-end activities with GDB/MI traces
- Back-end breakpoint status with "info break" at the console
- Platform breakpoint status in Breakpoint View (with Breakpoint Properties)
- Launch the Eclipse workbench
- Start a DSF debug session (DsfBreakpoints)
Test 1: Breakpoint setting
- In the editor, add a new line breakpoint (BP-1)
- Check: A new breakpoint is inserted and it is enabled
- In the view menu: enable the "Show Full Paths" check box
- Check: The breakpoint full path is displayed in the view
- In the editor, disable the "Show Full Paths" check box
- Check: The breakpoint full path is not displayed in the view
- In the editor, add a new line breakpoint (BP-1)
Test 2: Breakpoint activation
- In the editor, disable BP-1
- Check: BP-1 is disabled
- In the editor, enable BP-1
- Check: BP-1 is enabled
- From the breakpoint context menu, disable BP-1
- Check: BP-1 is disabled
- From the breakpoint context menu, enable BP-1
- Check: BP-1 is enabled
- In the editor, disable BP-1
Test 3: Breakpoint condition
- Set an invalid condition on BP-1
- Check: The update is rejected and BP-1 is not changed
- Set a valid condition on BP-1
- Check: The update is accepted and BP-1 has the new condition
- Set an invalid condition on BP-1
- Check: The update is rejected and BP-1 kept the valid condition
- Clear the BP-1 condition
- Check: The update is accepted and BP-1 no longer has a condition
- Set an invalid condition on BP-1
Test 4: Breakpoint ignore count
- Set an ignore count on BP-1
- Check: The update is accepted and BP-1 has the new ignore count
- Reset an ignore count on BP-1 (set to 0)
- Check: The update is accepted and BP-1 has no ignore count
- Set an ignore count on BP-1
- Test 5: Breakpoint deletion (simple)
- From the GUI, delete BP-1
- Check: BP-1 is removed
- From the GUI, delete BP-1
Test 6: Breakpoint persistence
- Create 4 breakpoints with the following characteristics:
- BP-1: enabled, no condition, no ignore count
- BP-2: disabled, with condition, no ignore count
- BP-3: disabled, no condition, with ignore count
- BP-4: enabled, with condition, with ignore count
- Check: The 4 breakpoints are correctly created
- Terminate the debugging session
- Start a new debugging session
- Check: The 4 breakpoints are correctly restored
- Terminate the debugging session
- Enable all breakpoints
- Start a new debugging session
- Check: The 4 breakpoints are correctly restored (and enabled)
- Create 4 breakpoints with the following characteristics:
Test 7: Import/export breakpoints to file
- Create 4 breakpoints with the following characteristics (re-use the ones from previous step):
- BP-1: enabled, no condition, no ignore count
- BP-2: disabled, with condition, no ignore count
- BP-3: disabled, no condition, with ignore count
- BP-4: enabled, with condition, with ignore count
- Check: The 4 breakpoints are correctly created
- Export the 4 breakpoints to file
- Check: The breakpoints file is created
- Remove all breakpoints
- Check: The 4 breakpoints are removed
- Import the breakpoint file
- Check: The 4 breakpoints are correctly restored
- Remove all breakpoints
- Terminate the debugging session
- Start a new debugging session
- Check: No breakpoint is installed
- Import the breakpoint file
- Check: The 4 breakpoints are correctly restored
- Create 4 breakpoints with the following characteristics (re-use the ones from previous step):
Test 8: Breakpoint deletion (multiple)
- From the GUI, delete BP-1, BP-2, BP-3 and BP-4
- Check: the 4 breakpoints are removed
- From the GUI, delete BP-1, BP-2, BP-3 and BP-4
Watchpoints (General)
Test Setup
- To avoid stack overflow, set memory to 512M
- In the launch configuration, Arguments tab, VM arguments section: -Xmx512M
- To ensure integrity between the UI and the back-end, all verifications (Check:) are performed from 3 points:
- Back-end activities with GDB/MI traces
- Back-end breakpoint status with "info break" at the console
- Platform breakpoint status in Breakpoint View (with Breakpoint Properties)
- Launch the Eclipse workbench
- Start a DSF debug session (DsfBreakpoints)
Test 1: Watchpoint setting
- In the Breakpoint View, add a new watchpoint (WP-1)
- Check: A new watchpoint is inserted and it is enabled
- In the Breakpoint View, add a new watchpoint (WP-1)
Test 2: Watchpoint activation
- From the watchpoint context menu. disable WP-1
- Check: WP-1 is disabled
- From the watchpoint context menu, enable WP-1
- Check: WP-1 is enabled
- From the watchpoint context menu. disable WP-1
Test 3: Watchpoint condition
- Set an invalid condition on WP-1
- Check: The update is rejected and WP-1 is not changed
- Set a valid condition on WP-1
- Check: The update is accepted and WP-1 has the new condition
- Set an invalid condition on WP-1
- Check: The update is rejected and WP-1 kept the valid condition
- Clear the WP-1 condition
- Check: The update is accepted and WP-1 no longer has a condition
- Set an invalid condition on WP-1
Test 4: Watchpoint ignore count
- Set an ignore count on WP-1
- Check: The update is accepted and WP-1 has the new ignore count
- Reset an ignore count on WP-1 (set to 0)
- Check: The update is accepted and WP-1 has no ignore count
- Set an ignore count on WP-1
Test 5: Watchpoint deletion (simple)
- From the GUI, delete WP-1
- Check: WP-1 is removed
- From the GUI, delete WP-1
Test 6: Watchpoint persistence
- Create 4 watchpoints with the following characteristics:
- WP-1 enabled, write, no condition, no ignore count
- WP-2 disabled, read, with condition, no ignore count
- WP-3 disabled, read/write, no condition, with ignore count
- WP-4 enabled, write, with condition, with ignore count
- Check: The 4 watchpoints are correctly created
- Terminate the debugging session
- Start a new debugging session
- Check: The 4 watchpoints are correctly restored
- Terminate the debugging session
- Enable all watchpoints
- Start a new debugging session
- Check: The 4 watchpoints are correctly restored (and enabled)
- Create 4 watchpoints with the following characteristics:
Test 7: Import/export watchpoints to file
- Create 4 watchpoints with the following characteristics (re-use watchpoints from previous step):
- WP-1 enabled, write, no condition, no ignore count
- WP-2 disabled, read, with condition, no ignore count
- WP-3 disabled, read/write, no condition, with ignore count
- WP-4 enabled, write, with condition, with ignore count
- Check: The 4 watchpoints are correctly created
- Export the 4 watchpoints to file
- Check: The watchpoints file is created
- Remove all watchpoints
- Check: The 4 watchpoints are removed
- Import the watchpoints file
- Check: The 4 watchpoints are correctly restored
- Remove all watchpoints
- Terminate the debugging session
- Start a new debugging session
- Check: No watchpoints is installed
- Import the watchpoints file
- Check: The 4 watchpoints are correctly restored
- Create 4 watchpoints with the following characteristics (re-use watchpoints from previous step):
Test 8: Watchpoint deletion (multiple)
- From the GUI, delete WP-1, WP-2, WP-3 and WP-4
- Check: The 4 watchpoints are removed
- From the GUI, delete WP-1, WP-2, WP-3 and WP-4
Skip All (Breakpoints) Button
Test Setup
- To avoid stack overflow, set memory to 512M
- In the launch configuration, Arguments tab, VM arguments section: -Xmx512M
- To ensure integrity between the UI and the back-end, all verifications (Check:) are performed from 3 points:
- Back-end activities with GDB/MI traces
- Back-end breakpoint status with "info break" at the console
- Platform breakpoint status in Breakpoint View (with Breakpoint Properties)
- Launch the Eclipse workbench
- Create 3 line breakpoints (anything will do)
- Start a DSF debug session (DsfBreakpoints)
- Check: Breakpoints are created and enabled
Test 1: Simple ON/OFF
- Toggle the 'Skip All Button' SAB to ON
- Check: BPs 1, 2, 3 are disabled
- Toggle the SAB to OFF
- Check: BPs 1, 2, 3 are enabled
- Toggle the 'Skip All Button' SAB to ON
Test 2: ON/OFF with some disabled BPs
- Disable BP 2
- Check: Only BP-2 is disabled
- Toggle the SAB to ON
- Check: All breakpoints are disabled
- Toggle the SAB to OFF
- Check: BPs 1, 3 are enabled
- Disable BP 1 and 3
- Enable BP 2
- Check: Only BP-2 is enabled
- Toggle the SAB to ON
- Check: All breakpoints are disabled
- Toggle the SAB to OFF
- Check: Only BP-2 is enabled
- Disable BP 2
Test 3: ON/OFF with all BPs disabled
- Disable BPs 1, 2, 3
- Toggle the SAB to ON
- Check: Nothing happens
- Toggle the SAB to OFF
- Check: Nothing happens
Test 4: Change BPs state while OFF
- Enable BP 2
- Disable BPs 1, 3
- Toggle the SAB to ON
- Check: BP 2 is disabled
- Enable BP 1
- Check: Nothing happens
- Disable BP 2
- Check: Nothing happens
- Toggle the SAB to OFF
- Check: BP 1 is enabled
Test 6: Startup
- Terminate DSF debug session
- Enable BPs 1, 2, 3
- Toggle the SAB to ON
- Start DSF debug session
- Check: BPs 1, 2, 3 are created and disabled
- Toggle the SAB to OFF
- Check: BPs 1, 2, 3 are enabled