C Checker Reference Manual

January 1998

next section previous section current document TenDRA home page document index


9.1 - Introduction
9.2 - Unused headers
9.3 - Error processing
9.4 - API usage analysis
9.5 - Intermodular checks

9 Symbol Table Dump


9.1 Introduction

Tchk produces an extra output file, called a dump output file, for each translation unit processed. This file is in the form given by the symbol table output specification in Annex E, and contains information about the objects declared, defined or used within an application. Each object encountered during processing is assigned a unique reference number allowing uses of the object to be traced back to the declaration and definition of the object.

In the default mode only external declaration and definition information is written to each dump file. The amount of information output may be increased by passing the -sym[cehklsu] command line option to tchk. Any combination of the optional flags enclosed by [] may be used and the effect of each flag is described below:

The dump information is currently used for four main purposes: detecting included header files from which nothing is used within the translation unit; production of lint-like error output; API usage analysis and type checking between translation units.


9.2 Unused headers

Header files which are included but from which nothing is used within the other source files comprising the translation unit, might just as well not have been included. Tchk can detect top level include files which are unnecessary, by analysing the dump output for the file. This check is enabled by passing the -Wd,-H command line flag to tchk. Errors are written to stderr in a simple ascii form by default, or to the unified dump file in dump format if the -D command line option is used.


9.3 Error processing

By default the error messages generated by the checker are written in a simple ascii form to stderr. If instead, the errors are written to the dump file using the -sym:e option mentioned above, an alternative lint-like error output may be generated by processing the dump files. The lint-like errors are enabled by passing the -Ycompact flag to tchk.


9.4 API usage analysis

Analysis performed on the set of dump files produced for an entire application can detect the objects, types, etc. from external APIs which are used by the application. The API usage analysis is enabled by passing one or more -api_checkAPI flags to tchk where API may be any of the standard APIs listed in section 2.1. The -api_check_outFILE flag may be used to direct the API analysis information to the file FILE (by default it is written to stdout). The APIs used to perform API usage analysis may be different from those used to process the application. Annex G.8 contains details of the methods used to perform the API usage analysis.


9.5 Intermodular checks

All the checks discussed in earlier chapters have been concerned with a single source file. However, tchk also contains a linking phase in which it is able to perform intermodular checks (i.e. checks between source files). In the linking phase, the dumps file generated from each translation unit processed are combined into a single dump file containing information on all external objects within the application, and type consistency checks are applied to ensure that the definitions and declarations of each object are consistent and external objects and functions have at most one definition.

The amount of information about an object stored in a dump file depends on the compilation mode used to produce that file. For example, if extra prototype checks are enabled (see section 3.3), the dump file contains any information inferred about a function from its traditional style definition or from applications of that function. For example, if one file contains:

	extern void f () ;
	void g ()
	{
		f ( "hello" ) ;
	}
and another contained:

	void f ( n ) int n ;
	{
		return ;
	}
then the inferred prototype:

	void f WEAK ( char * ) ;
from the call of f would be included in the first dump file, whereas the weak prototype deduced from the definition of f:

	void f WEAK ( int ) ;
would be included in the second. When these two dump files are linked, the inconsistency is discovered and an error is reported.


Part of the TenDRA Web.
Crown Copyright © 1998.