Debugging services
Debugging services come in two flavors: low-level services such as register displays, examining and setting memory, single-stepping, and setting breakpoints, and system-oriented services such as observing the status of tasks, the contents of mail-boxes, or the list of allocated segments. As we proceed from unit test to system integration, the services we need change from low-level to system-oriented.

We usually do some unit testing in a PC environment. For iRMX systems, the operating system can't be present. In this case, we use our own shell to provide debug services. For example, we can use Get_Mail to provide any message that might be needed as input to a task. The task sees its actual interface, and only the shell has to be modified. (We believe it's fundamentally important that code, especially interfaces, not be changed to accommodate debugging.) When writing to VRTX, which can run on MS-DOS systems, we use the actual environment and have TRACER available.

To test single tasks or even small subsystems when we move to the target systems, we run under the target operating system and shell and use a special debug task. This task, Junk_Mail, provides us with a way of sending mail that in the complete system would originate from outside the unit or subsystem under test. It's an independent task, so it can be deleted from the final system build without affecting any operational code. The task itself contains a small segment that tests a variable called Item periodically. When Item becomes nonzero, a mail message is created and sent to some task in the system under test. Listing 4 shows a skeleton for a Junk_Mail task. Setting Item to a nonzero value can be done from an emulator or a debug terminal.

View the full-size image

During debugging, the iRMX debugger provides information on memory management for the tasks under test. As discussed earlier, iRMX can list all segments in use and we can check that the creation and deletion of segments by tasks (primarily related to mailing information between tasks) are performed as intended. VRTX, however, provides information only on the number of free segments available in each partition.

Here's where Send_Mail and Delete_Segment can help us. Send_Mail identifies each mailed segment with a mail code and the intended recipient. Delete_Segment zeros out these items and writes the deleting task's identification into the recipient's space. A dump of the heap area tells us which segments are active and which have been deleted. As a bonus, if two tasks try to delete the same segment, the source of the problem is readily apparent.

One of the first steps in system integration is verifying that all tasks and mailboxes have been created. iRMX provides a symbolic catalog of all objects known to it; symbols are assigned by the application when the object is created, and we need only examine the catalog for our verification. VRTX tells us only the identification numbers for active tasks and mailboxes. The actual names of objects can be found from these numbers, of course, but sometimes the translation is inconvenient.

Therefore, we've created a catalog that's entirely transparent to the application and hidden in the membrane services. (To implement the catalog efficiently, we used an array structure and were forced to constrain task and mailbox identifiers to integers in a predefined range; this is just about the only constraint placed on complete use of the operating system by our membranes.) The catalog allows us to define and examine symbolic names for objects the application creates. It can be disabled so that it doesn't take up any memory space when we move to an operational system. Again, this requires no changes to the operational code.

Once all the objects have been created, our approach is to watch the activity at mailboxes to verify intertask communications. Most of the handling of the communications has been checked out in unit testing. iRMX allows us to break when mail is sent to or received from a mailbox; VRTX doesn't provide this service. Again, we used our membranes to augment VRTX debugging services.

We structure Get_Mail, through the use of a subroutine, to provide a distinct return statement for each mailbox. This subroutine is created automatically by a macro as part of the operating system configuration. We can then break on the appropriate return statements to emulate the iRMX facility. In some senses, this is an improvement even on what iRMX provides since we're able to specify a break for only a certain task, whereas the iRMX facility is controlled by specifying mailboxes. By specifying a breakpoint that depends on a given task, we can determine immediately whether or not the right task got a message. For further debugging, the membranes routinely put the values of the mail code and sender into registers for easier access during a break.