Zeligsoft Limited Model level debugging

1. Zeligsoft LimitedModel level debugging May 2016 Simon Redding simon@zeligsoft.com Zeligsoft Proprietary

2. Outline • Common Debug support requirements • 3G Source level debugging • Model level debugging requirements • Current model level debugging • Proposed model level debug capabilities

3. Common Debug support requirements • Tracing and profiling – ability to capture information (timing) about execution with minimal additional overhead • Can be generic capture – usually flow control only • Custom trace instructions can be inserted – allows data values to be recorded • Breakpoint debugging • Suspend task/process and allow state inspection/modification • Inspect call stack to see how we got here and read/set values of locals and parameters • Conditional breakpoints – break on a value, after a number of hits, or some comparison condition • Information presented in a debugger should be easily relatable to the source program

4. 3G Source level debugging * learn to do hex arithmetic in your head • Debugging was first done at the assembler level. • Users maps back to source level statement and variables. Variable and state values are found by inspecting registers and memory • Time consuming, tedious and error prone* • Annotated listings with offsets and register assignments help map to source • Trace information is used to annotate source with hit counts • Source level debuggers overcame performance and accuracy issues and are now the norm • Users can set breakpoints, inspect/change values, in the source context

5. Model Level debugging requirements • Debug features should be equivalent to 3G language level – inspect model level elements (states, signals, parameters) • Models are a mixture of model constructs and user written C++ - need to debug at the level in which they are written • UML-RT models rely on message passing and state machines – different information is useful when debugging as compared to direct method invocation • Model debugger should look like model editor, but with the ability to inspect/change things

6. Only top level of stack trace is of interest Zeligsoft Proprietary

7. Current Model Level debugging

8. Proposed features • Tracing • Capture extended state* on each signal delivery • Breakpoint • Show capsule extended state • Inspect/change capsule attributes in the same syntax as presented by the model, not the C++ equivalent • Single step – execute next signal reception, choice or junction point • Support inspecting the extended state of other capsules in the application – GDB bt equivalent • Extended state history could also be recorded so past states can be examined – history depth would need to be limited * Capsule extended state history is {signal and params, SrcCapsule, SrcPort, CurrPort, FromState, CurrState, Transition}

9. Questions/comments