Scripting

A script is a list of commands in a file that MULTI reads and executes as if they were entered individually in the Debugger Command Pane. They typically end with .rc.

A script can contain both commands and expressions. It can contain if () {} else {} statements that could, for example, compare a program variable to a particular value and then perform some action based on that result.

You can use scripts for automating common tasks and for regression testing. By writing a command script that executes parts of your program and checks that your program is running correctly, you can rerun this script at a later date, after making supposedly unrelated changes, to verify that your program still runs the way you expect. See "Example 1: Connecting to a target from MULTI", for an example.

Creating a script

You can create a script automatically by use the > file command (see "Record and playback commands").

You can also manually create a script by putting the commands and expressions into a text file.

Running a script

You can run a script in the following ways:

In addition, you can save a script as one of the following startup scripts, which MULTI runs automatically at specific times:

Checking the syntax of your script

Syntax checking checks the validity of your command syntax without causing target interactions or changing system settings. You can check your script's syntax using:

In many debugging environments, it would be tedious to repeatedly run into syntax errors minutes or hours into a lengthy auto-debugging process. You could manually find the syntax errors by starting the process, making sure that all the breakpoints are hit and the associated commands are executed, and testing all of the script branches, but that can be very time-consuming. A better option is to use the sc command to check the syntax of your scripts before putting them into service.

The sc command has three limitations:

  1. It can't check syntax errors in commands associated with a breakpoint set with the bu command. The bu command sets up-level breakpoints; the context of the breakpoint depends on the dynamic execution. For example, in the command bu {print varA}, MULTI cannot determine the up-level procedure until the bu command is actually encountered while running the script. So, it has no way to check if the variable varA is a valid reference when syntax checking the script.
  2. sc cannot check the syntax errors in the body of a MULTI macro.
  3. sc treats all local variable references that are not in a breakpoint command as errors, as in the following script:

    b main#10 {if (argc>2) {print argc+i;} else {print
    "Too few arguments"}}
    print argc+i;
    print global_var;

    If the procedure main contains the number variables argc and i, and global_var is a global variable, sc will pass the first and the third lines. But sc treats the second line as error because MULTI cannot determine the context in which the print argc+i; command will be performed.

Related topic:


Previous

Next



Copyright © 1999, Green Hills Software. All rights reserved.