'Ambiguous Reference' when viewing variables

Description
When trying to view a global variable in a debugger (armsd, ADW or ADU) with e.g. print glob, the debugger may report "Error: Ambiguous Reference".
This will happen if there is more than one symbol called 'glob' in the debug symbol tables. There are three possible causes of this, described below.

1. Multiply #include'd static data
Suppose there is a header file test.h which contains a definition of a static variable
called 'glob':

static int glob = 0; 

Each time test.h is #include'd into a source file, a new instance of 'glob' will be created. Being a 'static', the scope of 'glob' is limited to the file which #include'd it (i.e. it is not global to all modules).

For example, if test.h is #include'd into two source files (file1.c and file2.c), two separate instances of 'glob' are created, each with the same name, but with a different scope. The first 'glob' has scope file1.c. The second 'glob' has scope file2.c, and so on. To see the location of the two 'glob's, type lsym. So, when you type print glob , the debugger does not know which 'glob' you are referring to, so (correctly) reports: "Ambiguous Reference".

To avoid this situation, simply remove the 'static' declaration in the header file to change 'glob' into an ordinary global.

2. Conditional #define's in headers
Another possible cause of "Ambiguous Reference" is the way the linker deletes common parts of the debugging information from DWARF2 output. As an example, consider two header files head1.h and head2.h, which both contain the following code:

#ifndef NULL
#define NULL 0
#endif 

Now consider two .c file source1.c and source2.c, which include the header files, but each in a different order. This means that in one case the #define is actioned in one header and in the other case the other. When the linker compares the debugging information for the two instances of each header file, it finds a difference and does not delete them. This essentially leaves two copies of the declaration information for the variable in the resulting image.

The workaround here is to modify the sources so that header files are included in the same order.

3. Mixed ASD and DWARF2 debug tables
"Ambiguous Reference" may also occur if you inadvertently build images containing a mix of ASD and DWARF2 debug tables. This can happen accidentally when migrating projects from SDT 2.11a to SDT 2.50/2.51, with C or C++.

An ARM Executable Image can contain debug information to allow you to debug the code at source level.

• For SDT 2.11/2.11a, the debug tables are in ASD format by default.
• For SDT 2.50/2.51, C++ 1.01/1.10/1.11 and ADS, the debug tables are in DWARF2 format by default.

There are of course differences in the debug information which DWARF2 and ASD provide.

At link time, the ARM linker links the code and data sections of the object modules, and adds in the debug tables (whether ASD or DWARF2 or both). If there are common (duplicate) sections in the debug tables for the various objects, the linker normally deletes the duplicate information, to reduce the overall image size.

However, if the objects contain a mix of ASD and DWARF2 debug tables, because of the differences between the DWARF2 and ASD sections, some of the duplicate will not be eliminated, resulting in two (slightly different) copies of the debug information being present in the output image. This can lead to the 'Ambiguous reference' problem.

If it is possible that some of your object modules have been compiled with SDT 2.11/2.11a (ASD), and that other modules have been compiled with SDT 2.50/2.51 or C++ (DWARF2), then try rebuilding your *entire* project (all modules) with the latest tools. This should eliminate the 'Ambiguous reference' problem.