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/8.4 Testing"

< CDT‎ | Obsolete
(Tests of new features)
(Regression tests)
Line 21: Line 21:
  
 
=== Regression tests ===
 
=== Regression tests ===
 
+
#Run DSF-GDB JUnit tests
'''Run DSF-GDB JUnit tests'''
+
#Enhanced Expressions
 
+
#Pretty-printing
'''Enhanced Expressions'''
+
#Process exit code shown in console
 
+
#Edit Tracepoint on Create
'''Pretty-printing'''
+
#Load information in the Multicore Visualizer - CPU/core load meters
 
+
#Multicore Visualizer enhanced selection and filtering
'''Process exit code shown in console'''
+
#Breakpoint Filtering
 
+
#OS Resources View
'''Edit Tracepoint on Create'''
+
#Step Into Selection
 
+
#Synchronization of GDB console
'''Load information in the Multicore Visualizer - CPU/core load meters'''
+
#* Breakpoints, watchpoints and tracepoints
 
+
#* Memory and variables
'''Multicore Visualizer enhanced selection and filtering'''
+
#* Reverse debugging state
 
+
#Breakpoint actions to control reverse debugging
'''Breakpoint Filtering'''
+
#Floating Point renderer of the memory package
 
+
#Debugging multiple processes within one debug session
'''OS Resources View'''
+
#Multicore Visualizer
 
+
#* Run a multi-threaded local debug session
'''Step Into Selection'''
+
#* Verify multicore visualizer shows all threads with proper state and coloring
 
+
#* verify sync with DV is happening
'''Synchronization of GDB console'''
+
#* verify drag-select works as expected
* Breakpoints, watchpoints and tracepoints
+
#* verify runcontrol buttons have the right state as different threads are selected
* Memory and variables
+
#* perform a multi-thread selection and press resume
* Reverse debugging state
+
#* verify all selected threads are resumed
 
+
#* perform a multi-thread selection and press suspend
'''Breakpoint actions to control reverse debugging'''
+
#* verify all selected threads are suspended
 
+
#* verify stepping works from the multicore visualizer when a single suspended thread is selected
'''Floating Point renderer of the memory package'''
+
#* verify the context menu has the runControl operations and select all and that they work as expected
 
+
#* start a second multi-threaded process
'''Debugging multiple processes within one debug session'''
+
#* verify that the new threads are shown in the visualizer
 
+
#* select a thread in the new process and press the terminate button in the visualizer
'''Multicore Visualizer'''
+
#* verify that only the relevant process is removed and the other keeps being debugged and displayed
* Run a multi-threaded local debug session
+
#Local Debug
* Verify multicore visualizer shows all threads with proper state and coloring
+
#* Launch a local debug session in non-stop mode
* verify sync with DV is happening
+
#* Verify that stepping works
* verify drag-select works as expected
+
#* Verify resumes works
* verify runcontrol buttons have the right state as different threads are selected
+
#* Verify suspend works
* perform a multi-thread selection and press resume
+
#* Verify that a breakpoint can be set while the target is running and does interrupt the execution when hit
* verify all selected threads are resumed
+
#* Verify that Run-to-line works in the same method (Ctrl-R)
* perform a multi-thread selection and press suspend
+
#* Verify that Run-to-line works in a different method (Ctrl-R)
* verify all selected threads are suspended
+
#* Look at variables view making sure the display is correct
* verify stepping works from the multicore visualizer when a single suspended thread is selected
+
#* Look at expressions view making sure the display is correct
* verify the context menu has the runControl operations and select all and that they work as expected
+
#* Look at registers view making sure the display is correct
* start a second multi-threaded process
+
#* Look at Memory view making sure memory can be displayed correctly
* verify that the new threads are shown in the visualizer
+
#* Look at Memory Browser view making sure memory can be displayed correctly
* select a thread in the new process and press the terminate button in the visualizer
+
#* Press the connect button on the Debug view
* verify that only the relevant process is removed and the other keeps being debugged and displayed
+
#* Press the "New..." button
**  Sanity tested with GDB 7.5 and works as expected.
+
#* Verify a prompt for a binary comes up
 
+
#* Select a binary
'''Local Debug'''
+
#* Verify that this binary starts being debugged
* Launch a local debug session in non-stop mode
+
#* Verify that there are two processes being debugged
* Verify that stepping works
+
#* Verify that the Debug view shows the cores next to each process and each thread
* Verify resumes works
+
#Local Attach
* Verify suspend works
+
#* Launch a local attach session in non-stop mode
* Verify that a breakpoint can be set while the target is running and does interrupt the execution when hit
+
#* Verify that there is a prompt to attach to a process
* Verify that Run-to-line works in the same method (Ctrl-R)
+
#* Press the "Cancel" button
* Verify that Run-to-line works in a different method (Ctrl-R)
+
#* Verify that the entire launch is terminated without error
* Look at variables view making sure the display is correct
+
#* Start three different long running programs
* Look at expressions view making sure the display is correct
+
#* Launch a local attach session in non-stop mode
* Look at registers view making sure the display is correct
+
#* Verify that there is a prompt to attach to a process
* Look at Memory view making sure memory can be displayed correctly
+
#* Verify that we can select multiple entries in that launch
* Look at Memory Browser view making sure memory can be displayed correctly
+
#* Select the three entries that were started earlier
* Press the connect button on the Debug view
+
#* Verifies that all three process start being debugged without being interrupted
* Press the "New..." button
+
#* Interrupt the second process
* Verify a prompt for a binary comes up
+
#* Set a breakpoint in the second process
* Select a binary
+
#* Resume the second process
* Verify that this binary starts being debugged
+
#* Verify that the second process stops at the breakpoint
* Verify that there are two processes being debugged
+
#* Set a breakpoint in the first process while it is running
* Verify that the Debug view shows the cores next to each process and each thread
+
#* Verify that the first process stops at the breakpoint
 
+
#* Detach from one process and see that it keeps on running but not debugged
'''Local Attach'''
+
#* Terminate from one process and see that it is killed
* Launch a local attach session in non-stop mode
+
#* Verify only one process is left being debugged
* Verify that there is a prompt to attach to a process
+
#* Press the connect button on the Debug view
* Press the "Cancel" button
+
#* Press the "Cancel" button
* Verify that the entire launch is terminated without error
+
#* Verify that the prompt disappears and that the debug session stays unchanged (one process being debugged)
* Start three different long running programs
+
#* Press the connect button on the Debug view
* Launch a local attach session in non-stop mode
+
#* Press the "New..." button
* Verify that there is a prompt to attach to a process
+
#* Verify a prompt for a binary comes up
* Verify that we can select multiple entries in that launch
+
#* Press the "Cancel" button
* Select the three entries that were started earlier
+
#* Verify that the prompt disappears and that the debug session stays unchanged (one process being debugged)
* Verifies that all three process start being debugged without being interrupted
+
#* Press the connect button on the Debug view
* Interrupt the second process
+
#* Press the "New..." button
* Set a breakpoint in the second process
+
#* Verify a prompt for a binary comes up
* Resume the second process
+
#* Select a binary
* Verify that the second process stops at the breakpoint
+
#* Verify that this binary starts being debugged
* Set a breakpoint in the first process while it is running
+
#* Verify that there are two processes being debugged
* Verify that the first process stops at the breakpoint
+
#Remote Attach
* Detach from one process and see that it keeps on running but not debugged
+
#* Start gdbserver --multi :9999
* Terminate from one process and see that it is killed
+
#* Launch a remote attach debug session to that target in non-stop mode
* Verify only one process is left being debugged
+
#* Verify the connection is made but nothing else happens
* Press the connect button on the Debug view
+
#* Start three long running processes on the target
* Press the "Cancel" button
+
#* Press the connect button on the Debug view
* Verify that the prompt disappears and that the debug session stays unchanged (one process being debugged)
+
#* Select all three processes started earlier
* Press the connect button on the Debug view
+
#* Verify there is a prompt for the binary of each process
* Press the "New..." button
+
#* Verify the title of the prompt shows which binary is being requested
* Verify a prompt for a binary comes up
+
#* Verifies that all three processes start being debugged without being interrupted
* Press the "Cancel" button
+
#* Interrupt the second process
* Verify that the prompt disappears and that the debug session stays unchanged (one process being debugged)
+
#* Set a breakpoint in the second process
* Press the connect button on the Debug view
+
#* Resume the second process
* Press the "New..." button
+
#* Verify that the second process stops at the breakpoint
* Verify a prompt for a binary comes up
+
#* Set a breakpoint in the first process while it is running
* Select a binary
+
#* Verify that the first process stops at the breakpoint
* Verify that this binary starts being debugged
+
#* Detach from one process and see that it keeps on running but not debugged
* Verify that there are two processes being debugged
+
#* Terminate from one process and see that it is killed
 
+
#* Verify only one process is left being debugged
'''Remote Attach'''
+
#* Press the connect button on the Debug view
* Start gdbserver --multi :9999
+
#* Press on "New..."
* Launch a remote attach debug session to that target in non-stop mode
+
#* Enter the paths of a binary on host and target (same binary) and press "Ok"
* Verify the connection is made but nothing else happens
+
#* Verify that the binary starts being debugged
* Start three long running processes on the target
+
#Post-mortem Core file
* Press the connect button on the Debug view
+
#* Start a local debug session
* Select all three processes started earlier
+
#* Step or resume to another method of the program
* Verify there is a prompt for the binary of each process
+
#* Make sure all threads are interrupted
* Verify the title of the prompt shows which binary is being requested
+
#* in the gdb console type 'gcore /tmp/gcore1' to generate a core file
* Verifies that all three processes start being debugged without being interrupted
+
#* Start a post-mortem debug session using /tmp/gcore1
* Interrupt the second process
+
#* Verify the debug view shows the program stopped where the core file was generated
* Set a breakpoint in the second process
+
#* Verify all step and resume buttons are grayed out
* Resume the second process
+
#* Verify variables are shown in variables view
* Verify that the second process stops at the breakpoint
+
#* Start a post-mortem debug session leaving the core file field empty
* Set a breakpoint in the first process while it is running
+
#* Verify a prompt for a core file is displayed
* Verify that the first process stops at the breakpoint
+
#* Press the "Cancel" button
* Detach from one process and see that it keeps on running but not debugged
+
#* Verify that the entire launch is terminated without error
* Terminate from one process and see that it is killed
+
#* Start a post-mortem debug session leaving the core file field empty
* Verify only one process is left being debugged
+
#* Verify a prompt for a core file is displayed
* Press the connect button on the Debug view
+
#* select /tmp/gcore1
* Press on "New..."
+
#* Verify the core file starts being 'debugged' as it was in the previous attempt
* Enter the paths of a binary on host and target (same binary) and press "Ok"
+
#* Start a post-mortem debug session only putting /tmp is the core file field
* Verify that the binary starts being debugged
+
#* Verify a prompt for a core file is displayed starting in /tmp
 
+
#* select gcore1
'''Post-mortem Core file'''
+
#* Verify the core file starts being 'debugged' as it was in the previous attempt
* Start a local debug session
+
#Automatic Remote Debug
* Step or resume to another method of the program
+
#* Start an Automatic Remote debug session
* Make sure all threads are interrupted
+
#* verify the process is being debugged
* in the gdb console type 'gcore /tmp/gcore1' to generate a core file
+
#Manual Remote Debug
* Start a post-mortem debug session using /tmp/gcore1
+
#* Start gdbserver (without --multi) with a binary
* Verify the debug view shows the program stopped where the core file was generated
+
#* Start an Manual Remote debug session to that target
* Verify all step and resume buttons are grayed out
+
#* verify the process is being debugged
* Verify variables are shown in variables view
+
#Tracepoints tests
* Start a post-mortem debug session leaving the core file field empty
+
#* Launch an Automatic Remote Debug session in Non-stop mode
* Verify a prompt for a core file is displayed
+
#* Create two tracepoints in the editor
* Press the "Cancel" button
+
#* Add the following actions to the first tracepoint: 'collect $locals' and 'collect $reg'
* Verify that the entire launch is terminated without error
+
#* Add the following actions to the second tracepoint: 'collect $trace_timestamp' and 'collect <single local var>'
* Start a post-mortem debug session leaving the core file field empty
+
#* Start trace experiment
* Verify a prompt for a core file is displayed
+
#* Resume program execution
* select /tmp/gcore1
+
#* Wait until trace data is collected (look at Trace Control view)
* Verify the core file starts being 'debugged' as it was in the previous attempt
+
#* Stop trace experiment
* Start a post-mortem debug session only putting /tmp is the core file field
+
#* Save trace data using Trace Control view view-menu
* Verify a prompt for a core file is displayed starting in /tmp
+
#* In the Trace Control view, press the Next Record button and navigate through the collected records
* select gcore1
+
#* Look at Variables view and Debug view to see that the collected data is properly displayed
* Verify the core file starts being 'debugged' as it was in the previous attempt
+
#* Make sure that unavailable data shows "<unavailable>" in the Variables view
 
+
#* Launch a Post-mortem Tracing debug session using the trace data file saved in the previous test case
'''Automatic Remote Debug'''
+
#* In the Trace Control view, press the Next Record button and navigate through the collected records
* Start an Automatic Remote debug session
+
#* Look at Variables view and Debug view to see that the collected data is properly displayed
* verify the process is being debugged
+
#* Make sure that unavailable data shows "<unavailable>" in the Variables view
 
+
#* Launch a Post-mortem Tracing debug session leaving the trace data field empty
'''Manual Remote Debug'''
+
#* Verify that a prompt is displayed to select the trace data file
* Start gdbserver (without --multi) with a binary
+
#* Select the trace data file saved in the previous test case
* Start an Manual Remote debug session to that target
+
#* In the Trace Control view, press the Next Record button and navigate through the collected records
* verify the process is being debugged
+
#* Look at Variables view and Debug view to see that the collected data is properly displayed
 
+
#* Make sure that unavailable data shows "<unavailable>" in the Variables view
'''Tracepoints tests'''
+
#* Launch a Post-mortem Tracing debug session having the trace data field only contain a directory
* Launch an Automatic Remote Debug session in Non-stop mode
+
#* Verify a prompt for a trace file is displayed starting in the specified directory
* Create two tracepoints in the editor
+
#Fast Tracepoint tests
* Add the following actions to the first tracepoint: 'collect $locals' and 'collect $reg'
+
#* create two tracepoints in the same program
* Add the following actions to the second tracepoint: 'collect $trace_timestamp' and 'collect <single local var>'
+
#* Launch an automatic remote debug session in non-stop with the fast tracepoint option
* Start trace experiment
+
#* verify that only fast tracepoint are created, or no tracepoint if a fast tp cannot be created
* Resume program execution
+
#* verify that tracepoints are shown properly in the Disassembly view
* Wait until trace data is collected (look at Trace Control view)
+
#* Launch an automatic remote debug session in non-stop with the normal tracepoint option
* Stop trace experiment
+
#* verify that only two normal tracepoint are created
* Save trace data using Trace Control view view-menu
+
#* verify that tracepoints are shown properly in the Disassembly view
* In the Trace Control view, press the Next Record button and navigate through the collected records
+
#* Launch an automatic remote debug session in non-stop with the automatic tracepoint option
* Look at Variables view and Debug view to see that the collected data is properly displayed
+
#* verify that fast tracepoints are created, or normal tracepoint if a fast tp cannot be created
* Make sure that unavailable data shows "<unavailable>" in the Variables view
+
#* verify that tracepoints are shown properly in the Disassembly view
* Launch a Post-mortem Tracing debug session using the trace data file saved in the previous test case
+
#* delete and re-create the tracepoints directly in the Disassembly view
* In the Trace Control view, press the Next Record button and navigate through the collected records
+
#* verify the breakpoints are created in GDB as expected
* Look at Variables view and Debug view to see that the collected data is properly displayed
+
#Reverse Debugging
* Make sure that unavailable data shows "<unavailable>" in the Variables view
+
#* Launch a local debug session in all-stop mode (reverse debugging is not supported in non-stop)
* Launch a Post-mortem Tracing debug session leaving the trace data field empty
+
#* Customize the perspective to show the reverse debugging toggle button
* Verify that a prompt is displayed to select the trace data file
+
#* Verify that the button appears on the global toolbar or the debug view toolbar (depending on your settings)
* Select the trace data file saved in the previous test case
+
#* Toggle reverse debugging
* In the Trace Control view, press the Next Record button and navigate through the collected records
+
#* Verify the reverse debugging buttons for reverse and step appear properly
* Look at Variables view and Debug view to see that the collected data is properly displayed
+
#* Do some forward and reverse debugging
* Make sure that unavailable data shows "<unavailable>" in the Variables view
+
#* Verify that stepping works properly both ways
* Launch a Post-mortem Tracing debug session having the trace data field only contain a directory
+
#* Verify resumes works properly both ways
* Verify a prompt for a trace file is displayed starting in the specified directory
+
 
+
'''Fast Tracepoint tests'''
+
* create two tracepoints in the same program
+
* Launch an automatic remote debug session in non-stop with the fast tracepoint option
+
* verify that only fast tracepoint are created, or no tracepoint if a fast tp cannot be created
+
* verify that tracepoints are shown properly in the Disassembly view
+
* Launch an automatic remote debug session in non-stop with the normal tracepoint option
+
* verify that only two normal tracepoint are created
+
* verify that tracepoints are shown properly in the Disassembly view
+
* Launch an automatic remote debug session in non-stop with the automatic tracepoint option
+
* verify that fast tracepoints are created, or normal tracepoint if a fast tp cannot be created
+
* verify that tracepoints are shown properly in the Disassembly view
+
* delete and re-create the tracepoints directly in the Disassembly view
+
* verify the breakpoints are created in GDB as expected
+
 
+
'''Reverse Debugging'''
+
* Launch a local debug session in all-stop mode (reverse debugging is not supported in non-stop)
+
* Customize the perspective to show the reverse debugging toggle button
+
* Verify that the button appears on the global toolbar or the debug view toolbar (depending on your settings)
+
* Toggle reverse debugging
+
* Verify the reverse debugging buttons for reverse and step appear properly
+
* Do some forward and reverse debugging
+
* Verify that stepping works properly both ways
+
* Verify resumes works properly both ways
+
  
 
== Completed ==
 
== Completed ==
 
The below tests have been completed.  Any issues found is indicated below the test entry.
 
The below tests have been completed.  Any issues found is indicated below the test entry.

Revision as of 16:17, 21 May 2014

Debug tests

To be run

The below tests have not be run yet. Once run, they can be moved to the 'completed' section below. These tests are suggestions of what should be tested, but are not exhaustive.

When someone decides to run some tests, they should put their name next to the section selected. This will avoid multiple people running the same tests.

Tests of new features

Dynamic-printf

Showing return value of method after a step-return

Trace Control view enhancements

Change breakpoint type

Opcodes in Disassembly View

Tooltip support in Multicore Visualizer

Regression tests

  1. Run DSF-GDB JUnit tests
  2. Enhanced Expressions
  3. Pretty-printing
  4. Process exit code shown in console
  5. Edit Tracepoint on Create
  6. Load information in the Multicore Visualizer - CPU/core load meters
  7. Multicore Visualizer enhanced selection and filtering
  8. Breakpoint Filtering
  9. OS Resources View
  10. Step Into Selection
  11. Synchronization of GDB console
    • Breakpoints, watchpoints and tracepoints
    • Memory and variables
    • Reverse debugging state
  12. Breakpoint actions to control reverse debugging
  13. Floating Point renderer of the memory package
  14. Debugging multiple processes within one debug session
  15. Multicore Visualizer
    • Run a multi-threaded local debug session
    • Verify multicore visualizer shows all threads with proper state and coloring
    • verify sync with DV is happening
    • verify drag-select works as expected
    • verify runcontrol buttons have the right state as different threads are selected
    • perform a multi-thread selection and press resume
    • verify all selected threads are resumed
    • perform a multi-thread selection and press suspend
    • verify all selected threads are suspended
    • verify stepping works from the multicore visualizer when a single suspended thread is selected
    • verify the context menu has the runControl operations and select all and that they work as expected
    • start a second multi-threaded process
    • verify that the new threads are shown in the visualizer
    • select a thread in the new process and press the terminate button in the visualizer
    • verify that only the relevant process is removed and the other keeps being debugged and displayed
  16. Local Debug
    • Launch a local debug session in non-stop mode
    • Verify that stepping works
    • Verify resumes works
    • Verify suspend works
    • Verify that a breakpoint can be set while the target is running and does interrupt the execution when hit
    • Verify that Run-to-line works in the same method (Ctrl-R)
    • Verify that Run-to-line works in a different method (Ctrl-R)
    • Look at variables view making sure the display is correct
    • Look at expressions view making sure the display is correct
    • Look at registers view making sure the display is correct
    • Look at Memory view making sure memory can be displayed correctly
    • Look at Memory Browser view making sure memory can be displayed correctly
    • Press the connect button on the Debug view
    • Press the "New..." button
    • Verify a prompt for a binary comes up
    • Select a binary
    • Verify that this binary starts being debugged
    • Verify that there are two processes being debugged
    • Verify that the Debug view shows the cores next to each process and each thread
  17. Local Attach
    • Launch a local attach session in non-stop mode
    • Verify that there is a prompt to attach to a process
    • Press the "Cancel" button
    • Verify that the entire launch is terminated without error
    • Start three different long running programs
    • Launch a local attach session in non-stop mode
    • Verify that there is a prompt to attach to a process
    • Verify that we can select multiple entries in that launch
    • Select the three entries that were started earlier
    • Verifies that all three process start being debugged without being interrupted
    • Interrupt the second process
    • Set a breakpoint in the second process
    • Resume the second process
    • Verify that the second process stops at the breakpoint
    • Set a breakpoint in the first process while it is running
    • Verify that the first process stops at the breakpoint
    • Detach from one process and see that it keeps on running but not debugged
    • Terminate from one process and see that it is killed
    • Verify only one process is left being debugged
    • Press the connect button on the Debug view
    • Press the "Cancel" button
    • Verify that the prompt disappears and that the debug session stays unchanged (one process being debugged)
    • Press the connect button on the Debug view
    • Press the "New..." button
    • Verify a prompt for a binary comes up
    • Press the "Cancel" button
    • Verify that the prompt disappears and that the debug session stays unchanged (one process being debugged)
    • Press the connect button on the Debug view
    • Press the "New..." button
    • Verify a prompt for a binary comes up
    • Select a binary
    • Verify that this binary starts being debugged
    • Verify that there are two processes being debugged
  18. Remote Attach
    • Start gdbserver --multi :9999
    • Launch a remote attach debug session to that target in non-stop mode
    • Verify the connection is made but nothing else happens
    • Start three long running processes on the target
    • Press the connect button on the Debug view
    • Select all three processes started earlier
    • Verify there is a prompt for the binary of each process
    • Verify the title of the prompt shows which binary is being requested
    • Verifies that all three processes start being debugged without being interrupted
    • Interrupt the second process
    • Set a breakpoint in the second process
    • Resume the second process
    • Verify that the second process stops at the breakpoint
    • Set a breakpoint in the first process while it is running
    • Verify that the first process stops at the breakpoint
    • Detach from one process and see that it keeps on running but not debugged
    • Terminate from one process and see that it is killed
    • Verify only one process is left being debugged
    • Press the connect button on the Debug view
    • Press on "New..."
    • Enter the paths of a binary on host and target (same binary) and press "Ok"
    • Verify that the binary starts being debugged
  19. Post-mortem Core file
    • Start a local debug session
    • Step or resume to another method of the program
    • Make sure all threads are interrupted
    • in the gdb console type 'gcore /tmp/gcore1' to generate a core file
    • Start a post-mortem debug session using /tmp/gcore1
    • Verify the debug view shows the program stopped where the core file was generated
    • Verify all step and resume buttons are grayed out
    • Verify variables are shown in variables view
    • Start a post-mortem debug session leaving the core file field empty
    • Verify a prompt for a core file is displayed
    • Press the "Cancel" button
    • Verify that the entire launch is terminated without error
    • Start a post-mortem debug session leaving the core file field empty
    • Verify a prompt for a core file is displayed
    • select /tmp/gcore1
    • Verify the core file starts being 'debugged' as it was in the previous attempt
    • Start a post-mortem debug session only putting /tmp is the core file field
    • Verify a prompt for a core file is displayed starting in /tmp
    • select gcore1
    • Verify the core file starts being 'debugged' as it was in the previous attempt
  20. Automatic Remote Debug
    • Start an Automatic Remote debug session
    • verify the process is being debugged
  21. Manual Remote Debug
    • Start gdbserver (without --multi) with a binary
    • Start an Manual Remote debug session to that target
    • verify the process is being debugged
  22. Tracepoints tests
    • Launch an Automatic Remote Debug session in Non-stop mode
    • Create two tracepoints in the editor
    • Add the following actions to the first tracepoint: 'collect $locals' and 'collect $reg'
    • Add the following actions to the second tracepoint: 'collect $trace_timestamp' and 'collect <single local var>'
    • Start trace experiment
    • Resume program execution
    • Wait until trace data is collected (look at Trace Control view)
    • Stop trace experiment
    • Save trace data using Trace Control view view-menu
    • In the Trace Control view, press the Next Record button and navigate through the collected records
    • Look at Variables view and Debug view to see that the collected data is properly displayed
    • Make sure that unavailable data shows "<unavailable>" in the Variables view
    • Launch a Post-mortem Tracing debug session using the trace data file saved in the previous test case
    • In the Trace Control view, press the Next Record button and navigate through the collected records
    • Look at Variables view and Debug view to see that the collected data is properly displayed
    • Make sure that unavailable data shows "<unavailable>" in the Variables view
    • Launch a Post-mortem Tracing debug session leaving the trace data field empty
    • Verify that a prompt is displayed to select the trace data file
    • Select the trace data file saved in the previous test case
    • In the Trace Control view, press the Next Record button and navigate through the collected records
    • Look at Variables view and Debug view to see that the collected data is properly displayed
    • Make sure that unavailable data shows "<unavailable>" in the Variables view
    • Launch a Post-mortem Tracing debug session having the trace data field only contain a directory
    • Verify a prompt for a trace file is displayed starting in the specified directory
  23. Fast Tracepoint tests
    • create two tracepoints in the same program
    • Launch an automatic remote debug session in non-stop with the fast tracepoint option
    • verify that only fast tracepoint are created, or no tracepoint if a fast tp cannot be created
    • verify that tracepoints are shown properly in the Disassembly view
    • Launch an automatic remote debug session in non-stop with the normal tracepoint option
    • verify that only two normal tracepoint are created
    • verify that tracepoints are shown properly in the Disassembly view
    • Launch an automatic remote debug session in non-stop with the automatic tracepoint option
    • verify that fast tracepoints are created, or normal tracepoint if a fast tp cannot be created
    • verify that tracepoints are shown properly in the Disassembly view
    • delete and re-create the tracepoints directly in the Disassembly view
    • verify the breakpoints are created in GDB as expected
  24. Reverse Debugging
    • Launch a local debug session in all-stop mode (reverse debugging is not supported in non-stop)
    • Customize the perspective to show the reverse debugging toggle button
    • Verify that the button appears on the global toolbar or the debug view toolbar (depending on your settings)
    • Toggle reverse debugging
    • Verify the reverse debugging buttons for reverse and step appear properly
    • Do some forward and reverse debugging
    • Verify that stepping works properly both ways
    • Verify resumes works properly both ways

Completed

The below tests have been completed. Any issues found is indicated below the test entry.

Back to the top