| 2 |
7u83 |
1 |
<!-- Crown Copyright (c) 1998 -->
|
|
|
2 |
<HTML>
|
|
|
3 |
<HEAD>
|
|
|
4 |
<TITLE>C Checker Reference Manual: Symbol Table Dump</TITLE>
|
|
|
5 |
</HEAD>
|
|
|
6 |
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
|
|
|
7 |
<A NAME=S114>
|
|
|
8 |
<H1>C Checker Reference Manual</H1>
|
|
|
9 |
<H3>January 1998</H3>
|
|
|
10 |
<A HREF="tdfc13.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
|
|
|
11 |
<A HREF="tdfc11.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
|
|
|
12 |
<A HREF="tdfc1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
|
|
|
13 |
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
|
|
|
14 |
</A>
|
|
|
15 |
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
|
|
|
16 |
<HR>
|
|
|
17 |
<DL>
|
|
|
18 |
<DT><A HREF="#S115"><B>9.1 </B> - Introduction</A><DD>
|
|
|
19 |
<DT><A HREF="#S116"><B>9.2 </B> - Unused headers</A><DD>
|
|
|
20 |
<DT><A HREF="#S117"><B>9.3 </B> - Error processing</A><DD>
|
|
|
21 |
<DT><A HREF="#S118"><B>9.4 </B> - API usage analysis
|
|
|
22 |
</A><DD>
|
|
|
23 |
<DT><A HREF="#S119"><B>9.5 </B> - Intermodular checks</A><DD>
|
|
|
24 |
</DL>
|
|
|
25 |
|
|
|
26 |
<HR>
|
|
|
27 |
<H1>9 Symbol Table Dump</H1>
|
|
|
28 |
<A NAME=S115>
|
|
|
29 |
<HR><H2>9.1 Introduction</H2>
|
|
|
30 |
Tchk produces an extra output file, called a dump output file, for
|
|
|
31 |
each translation unit processed. This file is in the form given by
|
|
|
32 |
the symbol table output specification in Annex E, and contains information
|
|
|
33 |
about the objects declared, defined or used within an application.
|
|
|
34 |
Each object encountered during processing is assigned a unique reference
|
|
|
35 |
number allowing uses of the object to be traced back to the declaration
|
|
|
36 |
and definition of the object. <P>
|
|
|
37 |
In the default mode only external declaration and definition information
|
|
|
38 |
is written to each dump file. The amount of information output may
|
|
|
39 |
be increased by passing the <CODE>-sym[cehklsu]</CODE>
|
|
|
40 |
command line option to tchk. Any combination of the optional flags
|
|
|
41 |
enclosed by [] may be used and the effect of each flag is described
|
|
|
42 |
below:<P>
|
|
|
43 |
<UL>
|
|
|
44 |
<LI>no flags external declarations, definitions only;<P>
|
|
|
45 |
<LI>c string and character literals output;<P>
|
|
|
46 |
<LI>e errors incorporated into dump output;<P>
|
|
|
47 |
<LI>e_only only errors output;<P>
|
|
|
48 |
<LI>h included headers output;<P>
|
|
|
49 |
<LI>k keywords output;<P>
|
|
|
50 |
<LI>l local variables output;<P>
|
|
|
51 |
<LI>s scopes output;<P>
|
|
|
52 |
<LI>u variable usage output.<P>
|
|
|
53 |
</UL>
|
|
|
54 |
The dump information is currently used for four main purposes: detecting
|
|
|
55 |
included header files from which nothing is used within the translation
|
|
|
56 |
unit; production of lint-like error output; API usage analysis and
|
|
|
57 |
type checking between translation units.<P>
|
|
|
58 |
<A NAME=S116>
|
|
|
59 |
<HR><H2>9.2 Unused headers</H2>
|
|
|
60 |
Header files which are included but from which nothing is used within
|
|
|
61 |
the other source files comprising the translation unit, might just
|
|
|
62 |
as well not have been included. Tchk can detect top level include
|
|
|
63 |
files which are unnecessary, by analysing the dump output for the
|
|
|
64 |
file. This check is enabled by passing the <CODE>-Wd,-H</CODE> command
|
|
|
65 |
line flag to tchk. Errors are written to stderr in a simple ascii
|
|
|
66 |
form by default, or to the unified dump file in dump format if the
|
|
|
67 |
<CODE>-D </CODE>command line option is used.<P>
|
|
|
68 |
<A NAME=S117>
|
|
|
69 |
<HR><H2>9.3 Error processing</H2>
|
|
|
70 |
By default the error messages generated by the checker are written
|
|
|
71 |
in a simple ascii form to stderr. If instead, the errors are written
|
|
|
72 |
to the dump file using the <CODE>-sym:e</CODE> option mentioned above,
|
|
|
73 |
an alternative lint-like error output may be generated by processing
|
|
|
74 |
the dump files. The lint-like errors are enabled by passing the <CODE>-Ycompact
|
|
|
75 |
</CODE> flag to tchk.<P>
|
|
|
76 |
<A NAME=S118>
|
|
|
77 |
<HR><H2>9.4 API usage analysis </H2>
|
|
|
78 |
Analysis performed on the set of dump files produced for an entire
|
|
|
79 |
application can detect the objects, types, etc. from external APIs
|
|
|
80 |
which are used by the application. The API usage analysis is enabled
|
|
|
81 |
by passing one or more <CODE>-api_check</CODE><EM>API</EM> flags to
|
|
|
82 |
tchk where <EM>API</EM> may be any of the standard APIs listed in
|
|
|
83 |
section 2.1. The <CODE>-api_check_out</CODE><EM>FILE</EM> flag may
|
|
|
84 |
be used to direct the API analysis information to the file <EM>FILE</EM>
|
|
|
85 |
(by default it is written to stdout). The APIs used to perform API
|
|
|
86 |
usage analysis may be different from those used to process the application.
|
|
|
87 |
Annex G.8 contains details of the methods used to perform the API
|
|
|
88 |
usage analysis.<P>
|
|
|
89 |
<A NAME=S119>
|
|
|
90 |
<HR><H2>9.5 Intermodular checks</H2>
|
|
|
91 |
All the checks discussed in earlier chapters have been concerned with
|
|
|
92 |
a single source file. However, tchk also contains a linking phase
|
|
|
93 |
in which it is able to perform intermodular checks (i.e. checks between
|
|
|
94 |
source files). In the linking phase, the dumps file generated from
|
|
|
95 |
each translation unit processed are combined into a single dump file
|
|
|
96 |
containing information on all external objects within the application,
|
|
|
97 |
and type consistency checks are applied to ensure that the definitions
|
|
|
98 |
and declarations of each object are consistent and external objects
|
|
|
99 |
and functions have at most one definition. <P>
|
|
|
100 |
The amount of information about an object stored in a dump file depends
|
|
|
101 |
on the compilation mode used to produce that file. For example, if
|
|
|
102 |
extra prototype checks are enabled (see section 3.3), the dump file
|
|
|
103 |
contains any information inferred about a function from its traditional
|
|
|
104 |
style definition or from applications of that function. For example,
|
|
|
105 |
if one file contains:<P>
|
|
|
106 |
<PRE>
|
|
|
107 |
extern void f () ;
|
|
|
108 |
void g ()
|
|
|
109 |
{
|
|
|
110 |
f ( "hello" ) ;
|
|
|
111 |
}
|
|
|
112 |
</PRE>
|
|
|
113 |
and another contained:<P>
|
|
|
114 |
<PRE>
|
|
|
115 |
void f ( n ) int n ;
|
|
|
116 |
{
|
|
|
117 |
return ;
|
|
|
118 |
}
|
|
|
119 |
</PRE>
|
|
|
120 |
then the inferred prototype:<P>
|
|
|
121 |
<PRE>
|
|
|
122 |
void f WEAK ( char * ) ;
|
|
|
123 |
</PRE>
|
|
|
124 |
from the call of f would be included in the first dump file, whereas
|
|
|
125 |
the weak prototype deduced from the definition of f:<P>
|
|
|
126 |
<PRE>
|
|
|
127 |
void f WEAK ( int ) ;
|
|
|
128 |
</PRE>
|
|
|
129 |
would be included in the second. When these two dump files are linked,
|
|
|
130 |
the inconsistency is discovered and an error is reported.<P>
|
|
|
131 |
<P>
|
|
|
132 |
<!-- FM pgf ignored -->
|
|
|
133 |
<HR>
|
|
|
134 |
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
|
|
|
135 |
Copyright © 1998.</I></P>
|
|
|
136 |
</BODY>
|
|
|
137 |
</HTML>
|