This is the top-most file in the project hierarchy. Some settings are only allowed in the Top Project: the project Build Target, Build Macro definitions, and a list of environment variables to import. Like other project files, it can contain programs, libraries, and other project files.

A general purpose container used to group programs, libraries, source code, and other projects.

This project contains information specific to the operating system and target board used for your project.

By default, all executables you create within your Top Project share one target resources project. This allows you to make modifications in one place (for example, altering a Linker Directives File), and to see the corresponding changes in all of your executables.

Project file that contains multiple source files, only one that is used in the build. These projects are generally used for multiple architecture hierarchies.

A container for grouping files which are automatically pulled in from a specified directory.

Ada source code.

C source code.

C++ source code.

C or C++ header file.

Generic text file.

MULTI command script.

Target configuration information for connecting to a simulator or to your target board via appropriate debug servers.

Setup script for initializing your target board.

Linker directives file that contains a memory map for the target board and a section map for the program.

Memory layout for your target board. This file is used by the Debugger to determine properties of various regions of memory.

Library file of object modules. These are typically used to specify binary libraries when there is no source available.

A quick tour of the MULTI Debugger.

This example demonstrates the capabilities of the MULTI source analysis tool, DoubleCheck. A library of C and C++ functions containing real bugs from production code is built with DoubleCheck enabled. Build this demo to see how DoubleCheck can help find bugs in your code.

This demonstration will give you an overview of the MULTI Debugger and its many debugging capabilities including:

Runtime Error Checking

Mixed-Language Debugging

Data Display

Using Advanced Breakpoints

Using Cross Reference Information

This example demonstrates what cross-referencing capabilities will do to make editing source code faster and easier. See how the MULTI Editor uses information from your source files to auto-complete symbol names, quickly jump to function definitions, and fill in function argument information.

This example will show you how to use the MULTI Debugger's code coverage analysis capabilities to find dead spots in your code.

This example project demonstrates the custom file type features of the MULTI Project Manager.

This example demonstrates how to set up a run-time error handler which will execute a user-defined action when your program encounters a run-time error.

This example demonstrates how you can use the MULTI Debugger to graph data values. This demo uses a C program.

This example demonstrates how you can use the MULTI Debugger to graph data values. This demo uses a C++ program.

This example demonstrates the memory leak detection capabilities of the MULTI Debugger.

This example demonstrates the built-in run-time error checking capabilities of the MULTI Debugger.

This example demonstrates the MULTI Debugger's ability to debug objects created from the C++ Standard Template Library.

This example shows how structures using pointers to link containers of data can be displayed by the MULTI Debugger.

Includes customizable source code for the Green Hills startup code library libstartup.a.

Includes customizable source code for the Green Hills system library libsys.a.

Includes customizable source code for the board initialization library libboardinit.a.

This library provides basic memory and peripheral initialization code to allow your program to be built for ROM or flash. It may also provide serial port code that allows standard I/O functions to use the serial port and support for target-based timer profiling.

Programs built with the board initialization library should be run on hardware targets. They may not work on a simulated target.

This example demonstrates using the PathAnalyzer with the MULTI TimeMachine Debugger.

This example demonstrates the PathAnalyzer and several other tools in the MULTI TimeMachine Debugger.

NOTE: This demo must be used with a datatrace-capable and gap-less trace collection interface.

This example demonstrates profiling using performance timing information.

This example demonstrates using the MULTI Debugger to attach to and debug a child process immediately after it is created using the fork system call.

This example demonstrates using the MULTI Debugger to attach to and debug a child process immediately after it is created using the exec system call.

This example demonstrates debugging a multi-threaded program in the MULTI Debugger.

This example demonstrates the profiling capabilities of the MULTI IDE.