3.1. Overview of CADI accesses from a debugger

Using the CADI interface requires specific calling schemes and procedures:

This chapter describes typical schemes and the general usage of the CADI interface from the caller side.

Note

Procedures that are described in separate chapters are only covered briefly in this one. See the referenced sections for more information on these topics.

A major aim of CADI 2.0 is to prevent the passing of data objects from the heap memory across dynamic library boundaries. To achieve this, each method call that passes information from the target to the caller must allocate data objects to receive the information. A pointer to this object is forwarded to the target which must fill it.

All CADI 2.0 data types provide a default constructor that initializes newly created data objects with reasonable values. This eliminates the risk that initialization is forgotten and unexpected behavior is caused by accident.

CADI 2.0 includes fundamental calling schemes for requesting hardware resource information and accessing these resources.

Methods in CADI 2.0 to request resource information typically have a prototype of the following form:

CADIReturn_t method_name(uint32_t startIndex,
                         uint32_t desiredNumOfElements,
                         uint32_t *actualNumOfElements, 
                         dataType *buffer);

The following guidelines must be followed for all CADI calls:

Other similar schemes exist. The returned CADIReturn_t and the actualNumOfElements parameter are set accordingly.

If querying certain resource information, the expected number can be usually obtained in the form of target properties returned by previous method calls. There are, however, some methods such as GetSimulationFactories() and GetSimulationInfos() for which the caller cannot know the exact number of properties in advance. For such calls, it is necessary to estimate a reasonable number that is sufficient to receive all expected items.

If the complete array is filled for such calls, it might be necessary to repeat the call with a larger array because a completely filled array might mean both a number of items that exactly matched the requested one and a number of items that was too small. Because this case cannot be excluded, it is therefore necessary to ask for more items to assure that all items have been acquired.

Copyright © 2008-2010 ARM Limited. All rights reserved.ARM DUI 0444F
Non-ConfidentialID110210