Go to most recent revision | Blame | Compare with Previous | Last modification | View Log | RSS feed
<!-- Crown Copyright (c) 1998 -->
<HTML>
<HEAD>
<TITLE>C Checker Reference Manual: Symbol Table Dump</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
<A NAME=S114>
<H1>C Checker Reference Manual</H1>
<H3>January 1998</H3>
<A HREF="tdfc13.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
<A HREF="tdfc11.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
<A HREF="tdfc1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
</A>
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
<HR>
<DL>
<DT><A HREF="#S115"><B>9.1 </B> - Introduction</A><DD>
<DT><A HREF="#S116"><B>9.2 </B> - Unused headers</A><DD>
<DT><A HREF="#S117"><B>9.3 </B> - Error processing</A><DD>
<DT><A HREF="#S118"><B>9.4 </B> - API usage analysis
</A><DD>
<DT><A HREF="#S119"><B>9.5 </B> - Intermodular checks</A><DD>
</DL>
<HR>
<H1>9 Symbol Table Dump</H1>
<A NAME=S115>
<HR><H2>9.1 Introduction</H2>
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. <P>
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 <CODE>-sym[cehklsu]</CODE>
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:<P>
<UL>
<LI>no flags external declarations, definitions only;<P>
<LI>c string and character literals output;<P>
<LI>e errors incorporated into dump output;<P>
<LI>e_only only errors output;<P>
<LI>h included headers output;<P>
<LI>k keywords output;<P>
<LI>l local variables output;<P>
<LI>s scopes output;<P>
<LI>u variable usage output.<P>
</UL>
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.<P>
<A NAME=S116>
<HR><H2>9.2 Unused headers</H2>
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 <CODE>-Wd,-H</CODE> 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
<CODE>-D </CODE>command line option is used.<P>
<A NAME=S117>
<HR><H2>9.3 Error processing</H2>
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 <CODE>-sym:e</CODE> 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 <CODE>-Ycompact
</CODE> flag to tchk.<P>
<A NAME=S118>
<HR><H2>9.4 API usage analysis </H2>
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 <CODE>-api_check</CODE><EM>API</EM> flags to
tchk where <EM>API</EM> may be any of the standard APIs listed in
section 2.1. The <CODE>-api_check_out</CODE><EM>FILE</EM> flag may
be used to direct the API analysis information to the file <EM>FILE</EM>
(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.<P>
<A NAME=S119>
<HR><H2>9.5 Intermodular checks</H2>
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. <P>
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:<P>
<PRE>
extern void f () ;
void g ()
{
f ( "hello" ) ;
}
</PRE>
and another contained:<P>
<PRE>
void f ( n ) int n ;
{
return ;
}
</PRE>
then the inferred prototype:<P>
<PRE>
void f WEAK ( char * ) ;
</PRE>
from the call of f would be included in the first dump file, whereas
the weak prototype deduced from the definition of f:<P>
<PRE>
void f WEAK ( int ) ;
</PRE>
would be included in the second. When these two dump files are linked,
the inconsistency is discovered and an error is reported.<P>
<P>
<!-- FM pgf ignored -->
<HR>
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
Copyright © 1998.</I></P>
</BODY>
</HTML>