CDT/Archive/cdt-debug-dsf-gdb

Features

Version support

• GDB 6.7+

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

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
  1. • Verify from the above test that the Debug view has a selection to the top-most thread
  2. Close Debug view
  3. Open Debug view
  4. 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)

• To avoid stack overflow, set memory to 512M
  1. 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:
  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)

Test Setup

• 1. Launch the Eclipse workbench
  2. 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