Jump to: navigation, search

CDT/cdt-debug-dsf-gdb

< CDT

Contents

Overview

Source

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

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

Automated testing

DSF-GDB has a JUnit4 test plugin, org.eclipse.cdt.tests.dsf.gdb, that is stored along-side the source code. This plugin aims at testing the different DSF-GDB services. There is currently no automated testing for UI operations. Such tests could eventually be added, maybe using SWTBOT, but until then, a manual test procedure is describe further down in this page. The rest of this section describes how to use the DSF-GDB JUnit tests.

The DSF-GDB JUnit tests are usually run on a Linux machine. At some time they were run on a Windows machine but the procedure is unclear.

Things to know

  • Each JUnit test is independent of the others. To achieve this, each JUnit test is a full-fledged DSF-GDB launch, with its own GDB instance.
  • Tests can be run locally, using a local GDB session
  • Tests can be run locally but using gdbserver. This simulates a remote debugging session. Dedicated remote test suites exists (see below) to trigger such tests.
  • Tracing can be turned on using the Tracing launch tab
  • Testing with different GDB version is supported
  • Automatically running the tests through maven is supported

Launching the tests manually

  • First make sure you have the proper GDB binaries you want to test. The tests are aimed at any of GDB 6.6, 6.7, 6.8, 7.0, and so on until the latest version of GDB available. Depending on the test suite you choose, the tests will be looking for the right GDB version in your PATH. The names of the gdb binaries should be:
    • gdb.6.6
    • gdb.6.7
    • etc
  • For 'remote' tests using gdbserver you must have the right gdbserver in your PATH:
    • gdbserver.6.6
    • gdbserver.6.7
    • etc

If you don't want to use your PATH variable to point to the GDB binaries, you can set the environment variable: cdt.tests.dsf.gdb.path to the directory where the GDB binaries are located. E.g., cdt.tests.dsf.gdb.path=/home/marc/bin/gdbBinaries

  • Create a new "JUnit Plug-in Test" configuration a choose the following options:
    • Under the "Test" tab:
      • Select "Run a single test"
      • The project is "org.eclipse.cdt.tests.dsf.gdb"
      • Choose a test class from the list described below (e.g., org.eclipse.cdt.tests.dsf.gdb.tests.tests_7_8.Suite_7_8, org.eclipse.cdt.tests.dsf.gdb.tests.AllSuites)
      • "Test runner" should be JUnit 4
    • Under the "Main" tab
      • Under "Program to Run", select "Run an application: [No Application] - Headless Mode"
    • Under the "Tracing" tab (if you want to enable 'gdb traces')
      • Check "org.eclipse.cdt.dsf.gdb on the left panel, then check 'debug' on the right panel
    • Press 'Debug'
      • A new window will (slowly) appear
      • You will see header printouts on the console of your development Eclipse for each test
      • If you've enabled tracing, you will see the gdb communication your development Eclipse

Available tests

Each test class tests a different DSF-GDB service. Tests suites allow running many test classes consecutively. Below is the list of the different suites and tests that can be run. Each element of the list can be chosen as the 'test class' in the launch.

  • org.eclipse.cdt.tests.dsf.gdb.tests.AllSuites - Runs every single test for every GDB version. You must make sure you have all the GDB binaries are in your PATH.
  • org.eclipse.cdt.tests.dsf.gdb.tests.tests_6_6.Suite_6_6 - Runs every test for gdb.6.6 (must be in your PATH)
  • org.eclipse.cdt.tests.dsf.gdb.tests.tests_6_7.Suite_6_7 - Runs every test for gdb.6.7 (must be in your PATH)
  • etc


  • org.eclipse.cdt.tests.dsf.gdb.tests.tests_6_6.Suite_Remote_6_6 - Runs every test for gdb.6.6 connecting to a gdbserver.6.6 (both must be in your PATH)
  • org.eclipse.cdt.tests.dsf.gdb.tests.tests_6_7.Suite_Remote_6_7 - Runs every test for gdb.6.7 connecting to a gdbserver.6.7 (both must be in your PATH)
  • etc


  • org.eclipse.cdt.tests.dsf.gdb.tests.AllTests - Deprecated. Will run the base tests with the GDB binary 'gdb' that is on the system. The problem is that only the base tests are chosen, which does not adapt to different GDB versions


  • Each test file can also be run individually, such as below. Again, the proper binary of GDB must be in your PATH
    • org.eclipse.cdt.tests.dsf.gdb.tests.tests_6_6.GDBProcessesTest_6_6
    • org.eclipse.cdt.tests.dsf.gdb.tests.tests_7_0.GDBProcessesTest_7_0

Writing new tests

Whenever a new feature is added new JUnit tests will probably called for. If the test falls into an existing DSF-GDB service, the corresponding test class should be enhanced with some new tests. Usually, it is not necessary to worry about GDB version when adding tests, as long as they are added in the base class. However, in some cases, the test should be different depending on the GDB version; in those cases, different test classes (based on the GDB version) will need to be updated.

If the feature creates a new service, different new test classes will need to be created. Depending on which GDB version will be used with the new service, different test classes will be created: a base test class, and a derived class for each GDB version. Also, the name of the new test classes must be added to all the relevant test Suite classes.

The class org.eclipse.cdt.tests.dsf.gdb.tests.ExampleTest is a template for writing new DSF-GDB JUnit test classes.

Testing using Maven

When building the CDT using Maven, the DSF-GDB tests will be run automatically using the latest GDB version as specified in org.eclipse.cdt.tests.dsf.gdb.tests.AutomatedSuite.java. This is driven by dsf-gdb/org.eclipse.cdt.tests.dsf.gdb/pom.xml. Both the location of the GDB binaries and which tests to run can be overridden using the following maven environment variables:

  • gdbPathOption=-Dcdt.tests.dsf.gdb.path=<path to GDB binaries>
  • gdbTestSuite=<full class name of suite or test file to be run>

For example:

mvn clean verify -DgdbPathOption=-Dcdt.tests.dsf.gdb.path=/home/marc/bin/gdbBinaries -DgdbTestSuite=Suite_7_8.java

will run the Suite_7_8 while looking for the corresponding GDB binary in /home/marc/bin/gdbBinaries.

Continuous Integration

Different jobs have been created on CDT's Hudson instance to test the different configurations for the Debug component.

  • cdt-master - This is the overall CDT build job for the master branch. It includes the DSF-GDB JUnit tests for the latest GDB version.
  • cdt-verify - This is the CDT job for patches pushed to Gerrit. It includes the DSF-GDB JUnit tests for the latest GDB version.
  • cdt-master-debug-tests - This jobs runs the local DSF-GDB tests of the master branch using all GDB versions. It is a separate job that runs once a day only because it takes a long time.
  • cdt-master-debug-remove-tests - This jobs runs the DSF-GDB tests of the master branch with gdbserver using all GDB versions. It is a separate job that runs once a day only because it takes a long time. It is separate from the 'cdt-master-debug-tests' job because the tests have the same names when running locally or with gdbserver, and would overwrite each other if put in the same job.
  • cdt-master-debug-tests-gdb-master - This job runs the DSF-GDB tests of the master branch against a GDB built from its own master branch. The idea is to detect any regression in GDB itself and allow us to notify the GDB community before any release.
  • cdt-master-debug-tests-gdb-maintenance - This job runs the DSF-GDB tests of the master branch against a GDB built from its own maintenance branch. The idea is to detect any regression in GDB's upcoming maintenance release and allow us to notify the GDB community before the release.

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