Subversion Repositories tendra.SVN

Rev

Rev 2 | Details | Compare with Previous | Last modification | View Log | RSS feed

Rev Author Line No. Line
2 7u83 1 
<!-- Crown Copyright (c) 1998 -->
2 
<HTML>
3 
<HEAD>
4 
<TITLE>
5 
C++ Producer Guide: Symbol table dump
6 
</TITLE>
7 
</HEAD>
8 
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
9 
 
10 
<H1>C++ Producer Guide</H1>
11 
<H3>March 1998</H3>
12 
<A HREF="link.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
13 
<A HREF="token.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
14 
<A HREF="index.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
15 
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
16 
</A>
17 
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
18 
<HR>
19 
 
20 
<DL>
21 
<DT><A HREF="#lex"><B>2.4.1</B> - Lexical elements</A><DD>
22 
<DT><A HREF="#main"><B>2.4.2</B> - Overall syntax</A><DD>
23 
<DT><A HREF="#loc"><B>2.4.3</B> - File locations</A><DD>
24 
<DT><A HREF="#id"><B>2.4.4</B> - Identifiers</A><DD>
25 
<DT><A HREF="#type"><B>2.4.5</B> - Types</A><DD>
26 
<DT><A HREF="#sort"><B>2.4.6</B> - Sorts</A><DD>
27 
<DT><A HREF="#args"><B>2.4.7</B> - Token applications</A><DD>
28 
<DT><A HREF="#error"><B>2.4.8</B> - Errors</A><DD>
29 
<DT><A HREF="#file"><B>2.4.9</B> - File inclusions</A><DD>
30 
<DT><A HREF="#string"><B>2.4.10</B> - String literals</A><DD>
31 
</DL>
32 
<HR>
33 
 
34 
<H2>2.4. Symbol table dump</H2>
35 
<P>
36 
The symbol table dump provides a method whereby third party tools
37 
can interface with the C and C++ producers.  The producer outputs
38 
information on the identifiers declared within a source file, their
39 
uses etc. into a file which can then be post-processed by a separate
40 
tool. Any error messages and warnings can also be included in this
41 
file, allowing more sophisticated error presentation tools to be written.
42 
</P>
43 
<P>
44 
The file to be used as the symbol table output file, plus details
45 
of what information is to be included in the dump file can be specified
46 
using the <A HREF="man.html#dump"><CODE>-d</CODE> command-line option</A>.
47 
The format of the dump file is described below; a
48 
<A HREF="dump1.html">summary of the syntax</A> is given as an annex.
49 
</P>
50 
 
51 
<HR>
52 
<H3><A NAME="lex">2.4.1. Lexical elements</A></H3>
53 
<P>
54 
A symbol table dump file consists of a sequence of characters giving
55 
information on identifiers, errors etc. arising from a translation
56 
unit. The fundamental lexical tokens are a <I>number</I>, consisting
57 
of a sequence of decimal digits, and a <I>string</I>, consisting of
58 
a sequence of characters enclosed in angle braces.  A <I>string</I>
59 
can have one of two forms:
60 
<PRE>
61 
	<I>string</I> :
62 
		&lt;<I>characters</I>&gt;
63 
		&amp;<I>number</I>&lt;<I>characters</I>&gt;
64 
</PRE>
65 
In the first form, the <I>characters</I> are terminated by the first
66 
<CODE>&gt;</CODE> character encountered.  In the second form, the
67 
number of characters is given by the preceding <I>number</I>.  No
68 
white space is allowed either before or after the <I>number</I>.
69 
To aid parsers, the C++ producer always uses the second form for strings
70 
containing more than 100 characters.  There are no escape characters
71 
in strings; the
72 
<I>characters</I> can contain any characters, including newlines and
73 
<CODE>#</CODE>, except that the first form cannot contain a
74 
<CODE>&gt;</CODE> character.
75 
</P>
76 
<P>
77 
Space, tab and newline characters are white space.  Comments begin
78 
with
79 
<CODE>#</CODE> and run to the end of the line.  Comments are treated
80 
as white space.  All other characters are treated as distinct lexical
81 
tokens.
82 
</P>
83 
 
84 
<HR>
85 
<H3><A NAME="main">2.4.2. Overall syntax</A></H3>
86 
<P>
87 
A symbol table dump file takes the form of a list of commands of various
88 
kinds conveying information on the analysed file.  This can be represented
89 
as follows:
90 
<PRE>
91 
	<I>dump-file</I> :
92 
		<I>command-list<SUB>opt</SUB></I>
93 
 
94 
	<I>command-list</I> :
95 
		<I>command command-list<SUB>opt</SUB></I>
96 
 
97 
	<I>command</I> :
98 
		<I>version-command</I>
99 
		<I>identifier-command</I>
100 
		<I>scope-command</I>
101 
		<I>override-command</I>
102 
		<I>base-command</I>
103 
		<I>api-command</I>
104 
		<I>template-command</I>
105 
		<I>promotion-command</I>
106 
		<I>error-command</I>
107 
		<I>path-command</I>
108 
		<I>file-command</I>
109 
		<I>include-command</I>
110 
		<I>string-command</I>
111 
</PRE>
112 
The various kinds of command are discussed below.  The first command
113 
in the dump file should be of the form:
114 
<PRE>
115 
	<I>version-command</I> :
116 
		V <I>number number string</I>
117 
</PRE>
118 
where the two numbers give the version of the dump file format (the
119 
version described here is 1.1 so both numbers should be 1) and the
120 
string gives the language being represented, for example,
121 
<CODE>&lt;C++&gt;</CODE>.
122 
</P>
123 
 
124 
<HR>
125 
<H3><A NAME="loc">2.4.3. File locations</A></H3>
126 
<P>
127 
A location within a source file can be specified using three
128 
<I>number</I>s and two <I>string</I>s.  These give respectively, the
129 
column number, the line number taking <CODE>#line</CODE> directives
130 
into account, the line number not taking <CODE>#line</CODE> directives
131 
into account, the file name taking <CODE>#line</CODE> directives into
132 
account, and the file name not taking <CODE>#line</CODE> directives
133 
into account.  Any or all of the trailing elements can be replaced
134 
by
135 
<CODE>*</CODE> to indicate that they have not changed relative to
136 
the last <I>location</I> given.  Note that for the two line numbers,
137 
unchanged means that the difference of the line numbers, taking
138 
<CODE>#line</CODE> directives into account or not, is unchanged.
139 
Thus:
140 
<PRE>
141 
	<I>location</I> :
142 
		<I>number number number string string</I>
143 
		<I>number number number string</I> *
144 
		<I>number number number</I> *
145 
		<I>number number</I> *
146 
		<I>number</I> *
147 
		*
148 
</PRE>
149 
Note that there is a concept of the <A NAME="crt_loc">current file
150 
location</A>, relative to which other locations are given.  The initial
151 
value of the current file location is undefined.  Unless otherwise
152 
stated, all <I>location</I> elements update the current file location.
153 
</P>
154 
 
155 
<HR>
156 
<H3><A NAME="id">2.4.4. Identifiers</A></H3>
157 
<P>
158 
Each identifier is represented in the symbol table dump by a unique
159 
number.  The same number always represents the same identifier.
160 
</P>
161 
 
162 
<H4><A NAME="hashid">Identifier names</A></H4>
163 
<P>
164 
The number representing an identifier is introduced in the first declaration
165 
or use of that identifier and thereafter the number alone is used
166 
to denote the identifier:
167 
<PRE>
168 
	<I>identifier</I> :
169 
		<I>number</I> = <I>identifier-name access<SUB>opt</SUB> scope-identifier</I>
170 
		<I>number</I>
171 
</PRE>
172 
</P>
173 
<P>
174 
The identifier name is given by:
175 
<PRE>
176 
	<I>identifier-name</I> :
177 
		<I>string</I>
178 
		C <I>type</I>
179 
		D <I>type</I>
180 
		O <I>string</I>
181 
		T <I>type</I>
182 
</PRE>
183 
denoting respectively, a simple identifier name, a constructor for
184 
a type, a destructor for a type, an overloaded operator function name,
185 
and a conversion function name.  The empty string is used for anonymous
186 
identifiers.
187 
</P>
188 
<P>
189 
The optional identifier access is given by:
190 
<PRE>
191 
	<I>access</I> :
192 
		N
193 
		B
194 
		P
195 
</PRE>
196 
denoting <CODE>public</CODE>, <CODE>protected</CODE> and
197 
<CODE>private</CODE> respectively.  An absent <I>access</I> is equivalent
198 
to <CODE>public</CODE>.  Note that all identifiers, not just class
199 
members, can have access specifiers; however the access of a non-member
200 
is always <CODE>public</CODE>.
201 
</P>
202 
<P>
203 
The <A HREF="#scope">scope</A> (i.e. class, namespace, block etc.)
204 
in which an identifier is declared is given by:
205 
<PRE>
206 
	<I>scope-identifier</I> :
207 
		<I>identifier</I>
208 
		*
209 
</PRE>
210 
denoting either a named or an unnamed scope.
211 
</P>
212 
 
213 
<H4><A NAME="use">Identifier uses</A></H4>
214 
<P>
215 
Each declaration or use of an identifier is represented by a command
216 
of the form:
217 
<PRE>
218 
	<I>identifier-command</I> :
219 
		D <I>identifier-info type-info</I>
220 
		M <I>identifier-info type-info</I>
221 
		T <I>identifier-info type-info</I>
222 
		Q <I>identifier-info</I>
223 
		U <I>identifier-info</I>
224 
		L <I>identifier-info</I>
225 
		C <I>identifier-info</I>
226 
		W <I>identifier-info type-info</I>
227 
</PRE>
228 
where:
229 
<PRE>
230 
	<I>identifier-info</I> :
231 
		<I>identifier-key location identifier</I>
232 
</PRE>
233 
gives the kind of identifier being declared or used, the location
234 
of the declaration or use, and the number associated with the identifier.
235 
Each declaration may, depending on the <I>identifier-key</I>, associate
236 
various <I>type-info</I> with the identifier, giving its type etc.
237 
</P>
238 
<P>
239 
The various kinds of <I>identifier-command</I> are described below.
240 
Any can be preceded by <CODE>I</CODE> to indicate an implicit declaration
241 
or use.  <CODE>D</CODE> denotes a definition.  <CODE>M</CODE> (make)
242 
denotes a declaration.  <CODE>T</CODE> denotes a tentative definition
243 
(C only).  <CODE>Q</CODE> denotes the end of a definition, for those
244 
identifiers such as classes and functions whose definitions may be
245 
spread over several lines.  <CODE>U</CODE> denotes an undefine operation
246 
(such as <CODE>#undef</CODE> for macro identifiers).  <CODE>C</CODE>
247 
denotes a call to a function identifier; <CODE>L</CODE> (load) denotes
248 
other identifier uses.  Finally <CODE>W</CODE> denotes implicit type
249 
information such as the C producer gleans from its
250 
<A HREF="pragma.html#weak">weak prototype analysis</A>.
251 
</P>
252 
<P>
253 
The various <I>identifier-key</I>s are their associated <I>type-info</I>
254 
fields are given by the following table:
255 
</P>
256 
<CENTER>
257 
<TABLE BORDER>
258 
<TR><TH>Key</TH>
259 
<TH>Type information</TH>
260 
<TH>Description</TH>
261 
<TR><TD ALIGN=CENTER><CODE>K</CODE></TD>
262 
<TD><CODE>*</CODE></TD>
263 
<TD>keyword</TD>
264 
<TR><TD ALIGN=CENTER><CODE>MO</CODE></TD>
265 
<TD><I>sort</I></TD>
266 
<TD>object macro</TD>
267 
<TR><TD ALIGN=CENTER><CODE>MF</CODE></TD>
268 
<TD><I>sort</I></TD>
269 
<TD>function macro</TD>
270 
<TR><TD ALIGN=CENTER><CODE>MB</CODE></TD>
271 
<TD><I>sort</I></TD>
272 
<TD>built-in macro</TD>
273 
<TR><TD ALIGN=CENTER><CODE>TC</CODE></TD>
274 
<TD><I>type</I></TD>
275 
<TD>class tag</TD>
276 
<TR><TD ALIGN=CENTER><CODE>TS</CODE></TD>
277 
<TD><I>type</I></TD>
278 
<TD>structure tag</TD>
279 
<TR><TD ALIGN=CENTER><CODE>TU</CODE></TD>
280 
<TD><I>type</I></TD>
281 
<TD>union tag</TD>
282 
<TR><TD ALIGN=CENTER><CODE>TE</CODE></TD>
283 
<TD><I>type</I></TD>
284 
<TD>enumeration tag</TD>
285 
<TR><TD ALIGN=CENTER><CODE>TA</CODE></TD>
286 
<TD><I>type</I></TD>
287 
<TD><CODE>typedef</CODE> name</TD>
288 
<TR><TD ALIGN=CENTER><CODE>NN</CODE></TD>
289 
<TD><CODE>*</CODE></TD>
290 
<TD>namespace name</TD>
291 
<TR><TD ALIGN=CENTER><CODE>NA</CODE></TD>
292 
<TD><I>scope-identifier</I></TD>
293 
<TD>namespace alias</TD>
294 
<TR><TD ALIGN=CENTER><CODE>VA</CODE></TD>
295 
<TD><I>type</I></TD>
296 
<TD>automatic variable</TD>
297 
<TR><TD ALIGN=CENTER><CODE>VP</CODE></TD>
298 
<TD><I>type</I></TD>
299 
<TD>function parameter</TD>
300 
<TR><TD ALIGN=CENTER><CODE>VE</CODE></TD>
301 
<TD><I>type</I></TD>
302 
<TD><CODE>extern</CODE> variable</TD>
303 
<TR><TD ALIGN=CENTER><CODE>VS</CODE></TD>
304 
<TD><I>type</I></TD>
305 
<TD><CODE>static</CODE> variable</TD>
306 
<TR><TD ALIGN=CENTER><CODE>FE</CODE></TD>
307 
<TD><I>type identifier<SUB>opt</SUB></I></TD>
308 
<TD><CODE>extern</CODE> function</TD>
309 
<TR><TD ALIGN=CENTER><CODE>FS</CODE></TD>
310 
<TD><I>type identifier<SUB>opt</SUB></I></TD>
311 
<TD><CODE>static</CODE> function</TD>
312 
<TR><TD ALIGN=CENTER><CODE>FB</CODE></TD>
313 
<TD><I>type identifier<SUB>opt</SUB></I></TD>
314 
<TD>built-in operator function</TD>
315 
<TR><TD ALIGN=CENTER><CODE>CF</CODE></TD>
316 
<TD><I>type identifier<SUB>opt</SUB></I></TD>
317 
<TD>member function</TD>
318 
<TR><TD ALIGN=CENTER><CODE>CS</CODE></TD>
319 
<TD><I>type identifier<SUB>opt</SUB></I></TD>
320 
<TD><CODE>static</CODE> member function</TD>
321 
<TR><TD ALIGN=CENTER><CODE>CV</CODE></TD>
322 
<TD><I>type identifier<SUB>opt</SUB></I></TD>
323 
<TD>virtual member function</TD>
324 
<TR><TD ALIGN=CENTER><CODE>CM</CODE></TD>
325 
<TD><I>type</I></TD>
326 
<TD>data member</TD>
327 
<TR><TD ALIGN=CENTER><CODE>CD</CODE></TD>
328 
<TD><I>type</I></TD>
329 
<TD><CODE>static</CODE> data member</TD>
330 
<TR><TD ALIGN=CENTER><CODE>E</CODE></TD>
331 
<TD><I>type</I></TD>
332 
<TD>enumerator</TD>
333 
<TR><TD ALIGN=CENTER><CODE>L</CODE></TD>
334 
<TD><CODE>*</CODE></TD>
335 
<TD>label</TD>
336 
<TR><TD ALIGN=CENTER><CODE>XO</CODE></TD>
337 
<TD><I>sort</I></TD>
338 
<TD>object token</TD>
339 
<TR><TD ALIGN=CENTER><CODE>XF</CODE></TD>
340 
<TD><I>sort</I></TD>
341 
<TD>procedure token</TD>
342 
<TR><TD ALIGN=CENTER><CODE>XP</CODE></TD>
343 
<TD><I>sort</I></TD>
344 
<TD>token parameter</TD>
345 
<TR><TD ALIGN=CENTER><CODE>XT</CODE></TD>
346 
<TD><I>sort</I></TD>
347 
<TD>template parameter</TD>
348 
</TABLE>
349 
</CENTER>
350 
<P>
351 
The function identifier keys can optionally be followed by
352 
<CODE>C</CODE> indicating that the function has C linkage, and
353 
<CODE>I</CODE> indicating that the function is inline.  By default,
354 
functions declared in a C++ dump file have C++ linkage and functions
355 
declared in a C dump file have C linkage.  The optional
356 
<I>identifier</I> which forms part of the <I>type-info</I> of these
357 
functions is used to form linked lists of overloaded functions.
358 
</P>
359 
 
360 
<H4><A NAME="scope">Identifier scopes</A></H4>
361 
<P>
362 
Each identifier belongs to a scope, called its parent scope, in which
363 
it is declared.  For example, the parent of a member of a class is
364 
the class itself.  This information is expressed in an identifier
365 
declaration using a <I>scope-identifier</I>.  In addition to the obvious
366 
scopes such as classes and namespaces, there are other scopes such
367 
as blocks in function definitions.  It is possible to introduce dummy
368 
identifiers to name such scopes.  The parent of such a dummy identifier
369 
will be the enclosing scope identifier, so these dummy identifiers
370 
naturally represent the block structure.  The parent of the top-level
371 
block in a function definition can be considered to be the function
372 
itself.
373 
</P>
374 
<P>
375 
Information on the start and end of such scopes is given by:
376 
<PRE>
377 
	<I>scope-command</I> :
378 
		SS <I>scope-key location identifier</I>
379 
		SE <I>scope-key location identifier</I>
380 
</PRE>
381 
where:
382 
<PRE>
383 
	<I>scope-key</I> :
384 
		N
385 
		S
386 
		B
387 
		D
388 
		H
389 
		CT
390 
		CF
391 
		CC
392 
</PRE>
393 
gives the kind of scope involved: a namespace, a class, a block, some
394 
other declarative scope, a declaration block (see below), a true conditional
395 
scope, a false conditional scope or a target dependent conditional
396 
scope.
397 
</P>
398 
<P>
399 
A declaration block is a sequence of declarations enclosed in directives
400 
of the form:
401 
<PRE>
402 
	#pragma TenDRA declaration block <I>identifier</I> begin
403 
	....
404 
	#pragma TenDRA declaration block end
405 
</PRE>
406 
This allows the sequence of declarations to be associated with the
407 
given
408 
<I>identifier</I> in the symbol dump file.  This technique is used
409 
in the API description files to aid analysis tools in determining
410 
which declarations are part of the API.
411 
</P>
412 
 
413 
<H4><A NAME="scope">Other identifier information</A></H4>
414 
<P>
415 
Other information associated with an identifier may be expressed using
416 
other dump commands.  For example:
417 
<PRE>
418 
	<I>override-command</I> :
419 
		O <I>identifier identifier</I>
420 
</PRE>
421 
is used to express the fact that the two <I>identifier</I>s are virtual
422 
member functions, the first of which overrides the second.
423 
</P>
424 
<P>
425 
The command:
426 
<PRE>
427 
	<I>base-command</I> :
428 
		B <I>identifier-key identifier base-graph</I>
429 
 
430 
	<I>base-graph</I> :
431 
		<I>base-class</I>
432 
		<I>base-class</I> ( <I>base-list</I> )
433 
 
434 
	<I>base-class</I> :
435 
		<I>number</I> = V<I><SUB>opt</SUB> access<SUB>opt</SUB> type-name</I>
436 
		<I>number</I> :
437 
 
438 
	<I>base-list</I> :
439 
		<I>base-graph base-list<SUB>opt</SUB></I>
440 
 
441 
</PRE>
442 
associates a base class graph with a class identifier.  Any class
443 
which does not have an associated <I>base-command</I> can be assumed
444 
to have no base classes.  Each node in the graph is a <I>type-name</I>
445 
with an associated list of base classes.  A <CODE>V</CODE> is used
446 
to indicate a virtual base class.  Each node is numbered; duplicate
447 
numbers are used to indicate bases identified via the virtual base
448 
class structure.  Any base class can then be referred to as:
449 
<PRE>
450 
	<I>base-number</I> :
451 
		<I>number</I> : <I>type-name</I>
452 
</PRE>
453 
indicating the base class with the given number in the given class.
454 
</P>
455 
<P>
456 
The command:
457 
<PRE>
458 
	<I>api-command</I> :
459 
		X <I>identifier-key identifier string</I>
460 
</PRE>
461 
associates the external token name given by the <I>string</I> with
462 
the given tokenised identifier.
463 
</P>
464 
<P>
465 
The command:
466 
<PRE>
467 
	<I>template-command</I> :
468 
		Z <I>identifier-key identifier token-application specialise-info</I>
469 
</PRE>
470 
is used to introduce an identifier corresponding to an instance of
471 
a template, <I>token-application</I>.  This instance may correspond
472 
to a specialisation of the primary template; this information is represented
473 
by:
474 
<PRE>
475 
	<I>specialise-info</I> :
476 
		<I>identifier</I>
477 
		<I>token-application</I>
478 
		*
479 
</PRE>
480 
where <CODE>*</CODE> indicates a non-specialised instance.
481 
</P>
482 
 
483 
<HR>
484 
<H3><A NAME="type">2.4.5. Types</A></H3>
485 
<P>
486 
The <A NAME="built-in">built-in types</A> are represented in the symbol
487 
table dump as follows:
488 
</P>
489 
<CENTER>
490 
<TABLE BORDER>
491 
<TR><TH>Type</TH>
492 
<TH>Encoding</TH>
493 
<TH>Type</TH>
494 
<TH>Encoding</TH>
495 
<TR><TD ALIGN=CENTER>char</TD>
496 
<TD ALIGN=CENTER><CODE>c</CODE></TD>
497 
<TD ALIGN=CENTER>float</TD>
498 
<TD ALIGN=CENTER><CODE>f</CODE></TD>
499 
<TR><TD ALIGN=CENTER>signed char</TD>
500 
<TD ALIGN=CENTER><CODE>Sc</CODE></TD>
501 
<TD ALIGN=CENTER>double</TD>
502 
<TD ALIGN=CENTER><CODE>d</CODE></TD>
503 
<TR><TD ALIGN=CENTER>unsigned char</TD>
504 
<TD ALIGN=CENTER><CODE>Uc</CODE></TD>
505 
<TD ALIGN=CENTER>long double</TD>
506 
<TD ALIGN=CENTER><CODE>r</CODE></TD>
507 
<TR><TD ALIGN=CENTER>signed short</TD>
508 
<TD ALIGN=CENTER><CODE>s</CODE></TD>
509 
<TD ALIGN=CENTER>void</TD>
510 
<TD ALIGN=CENTER><CODE>v</CODE></TD>
511 
<TR><TD ALIGN=CENTER>unsigned short</TD>
512 
<TD ALIGN=CENTER><CODE>Us</CODE></TD>
513 
<TD ALIGN=CENTER>(bottom)</TD>
514 
<TD ALIGN=CENTER><CODE>u</CODE></TD>
515 
<TR><TD ALIGN=CENTER>signed int</TD>
516 
<TD ALIGN=CENTER><CODE>i</CODE></TD>
517 
<TD ALIGN=CENTER>bool</TD>
518 
<TD ALIGN=CENTER><CODE>b</CODE></TD>
519 
<TR><TD ALIGN=CENTER>unsigned int</TD>
520 
<TD ALIGN=CENTER><CODE>Ui</CODE></TD>
521 
<TD ALIGN=CENTER>ptrdiff_t</TD>
522 
<TD ALIGN=CENTER><CODE>y</CODE></TD>
523 
<TR><TD ALIGN=CENTER>signed long</TD>
524 
<TD ALIGN=CENTER><CODE>l</CODE></TD>
525 
<TD ALIGN=CENTER>size_t</TD>
526 
<TD ALIGN=CENTER><CODE>z</CODE></TD>
527 
<TR><TD ALIGN=CENTER>unsigned long</TD>
528 
<TD ALIGN=CENTER><CODE>Ul</CODE></TD>
529 
<TD ALIGN=CENTER>wchar_t</TD>
530 
<TD ALIGN=CENTER><CODE>w</CODE></TD>
531 
<TR><TD ALIGN=CENTER>signed long long</TD>
532 
<TD ALIGN=CENTER><CODE>x</CODE></TD>
533 
<TD ALIGN=CENTER>-</TD>
534 
<TD ALIGN=CENTER>-</TD>
535 
<TR><TD ALIGN=CENTER>unsigned long long</TD>
536 
<TD ALIGN=CENTER><CODE>Ux</CODE></TD>
537 
<TD ALIGN=CENTER>-</TD>
538 
<TD ALIGN=CENTER>-</TD>
539 
</TABLE>
540 
</CENTER>
541 
<P>
542 
Named types (classes, enumeration types etc.) can be represented by
543 
the corresponding identifier or token application:
544 
<PRE>
545 
	<I>type-name</I> :
546 
		<I>identifier</I>
547 
		<I>token-application</I>
548 
</PRE>
549 
<A NAME="composite">Composite and qualified types</A> are represented
550 
in terms of their subtypes as follows:
551 
</P>
552 
<CENTER>
553 
<TABLE BORDER>
554 
<TR><TH>Type</TH>
555 
<TH>Encoding</TH>
556 
<TR><TD><CODE>const</CODE> type</TD>
557 
<TD><CODE>C</CODE> <I>type</I></TD>
558 
<TR><TD><CODE>volatile</CODE> type</TD>
559 
<TD><CODE>V</CODE> <I>type</I></TD>
560 
<TR><TD>pointer type</TD>
561 
<TD><CODE>P</CODE> <I>type</I></TD>
562 
<TR><TD>reference type</TD>
563 
<TD><CODE>R</CODE> <I>type</I></TD>
564 
<TR><TD>pointer to member type</TD>
565 
<TD><CODE>M</CODE> <I>type-name</I> <CODE>:</CODE> <I>type</I></TD>
566 
<TR><TD>function type</TD>
567 
<TD><CODE>F</CODE> <I>type parameter-types</I></TD>
568 
<TR><TD>array type</TD>
569 
<TD><CODE>A</CODE> <I>nat<SUB>opt</SUB></I> <CODE>:</CODE> <I>type</I></TD>
570 
<TR><TD>bitfield type</TD>
571 
<TD><CODE>B</CODE> <I>nat</I> <CODE>:</CODE> <I>type</I></TD>
572 
<TR><TD>template type</TD>
573 
<TD><CODE>t</CODE> <I>parameter-list<SUB>opt</SUB></I> <CODE>:</CODE> <I>type</I></TD>
574 
<TR><TD>promotion type</TD>
575 
<TD><CODE>p</CODE> <I>type</I></TD>
576 
<TR><TD>arithmetic type</TD>
577 
<TD><CODE>a</CODE> <I>type</I> <CODE>:</CODE> <I>type</I></TD>
578 
<TR><TD>integer literal type</TD>
579 
<TD><CODE>n</CODE> <I>lit-base<SUB>opt</SUB> lit-suffix<SUB>opt</SUB></I></TD>
580 
<TR><TD>weak function prototype (C only)</TD>
581 
<TD><CODE>W</CODE> <I>type parameter-types</I></TD>
582 
<TR><TD>weak parameter type (C only)</TD>
583 
<TD><CODE>q</CODE> <I>type</I></TD>
584 
</TABLE>
585 
</CENTER>
586 
<P>
587 
Other types can be represented by their textual representation using
588 
the form <CODE>Q</CODE> <I>string</I>, or by <CODE>*</CODE>, indicating
589 
an unknown type.
590 
</P>
591 
<P>
592 
The parameter types for a function type are represented as follows:
593 
<PRE>
594 
	<I>parameter-types</I> :
595 
		: <I>exception-spec<SUB>opt</SUB> func-qualifier<SUB>opt</SUB></I> :
596 
		. <I>exception-spec<SUB>opt</SUB> func-qualifier<SUB>opt</SUB></I> :
597 
		. <I>exception-spec<SUB>opt</SUB> func-qualifier<SUB>opt</SUB></I> .
598 
		, <I>type parameter-types</I>
599 
</PRE>
600 
where the <CODE>::</CODE> form indicates that there are no further
601 
parameters, the <CODE>.:</CODE> form indicates that the parameters
602 
are terminated by an ellipsis, and the <CODE>..</CODE> form indicates
603 
that no information is available on the further parameters (this can
604 
only happen with non-prototyped functions in C).  The function qualifiers
605 
are given by:
606 
<PRE>
607 
	<I>func-qualifier</I> :
608 
		C <I>func-qualifier<SUB>opt</SUB></I>
609 
		V <I>func-qualifier<SUB>opt</SUB></I>
610 
</PRE>
611 
representing <CODE>const</CODE> and <CODE>volatile</CODE> member functions.
612 
The function exception specifier is given by:
613 
<PRE>
614 
	<I>exception-spec</I> :
615 
		( <I>exception-list<SUB>opt</SUB></I> )
616 
 
617 
	<I>exception-list</I> :
618 
		<I>type</I>
619 
		<I>type</I> , <I>exception-list</I>
620 
</PRE>
621 
with an absent exception specifier, as in C++, indicating that any
622 
exception may be thrown.
623 
</P>
624 
<P>
625 
Array and bitfield sizes are represented as follows:
626 
<PRE>
627 
	<I>nat</I> :
628 
		+ <I>number</I>
629 
		- <I>number</I>
630 
		<I>identifier</I>
631 
		<I>token-application</I>
632 
		<I>string</I>
633 
</PRE>
634 
where a <I>string</I> is used to hold a textual representation of
635 
complex values.
636 
</P>
637 
<P>
638 
Template types are represented by a list of template parameters, which
639 
will have previously been declared using the <CODE>XT</CODE> identifier
640 
key, followed by the underlying type expressed in terms of these parameters.
641 
The parameters are represented as follows:
642 
<PRE>
643 
	<I>parameter-list</I> :
644 
		<I>identifier</I>
645 
		<I>identifier</I> , <I>parameter-list</I>
646 
</PRE>
647 
</P>
648 
<P>
649 
Integer literal types are represented by the value of the literal
650 
followed by a representation of the literal base and suffix.  These
651 
are given by:
652 
<PRE>
653 
	<I>lit-base</I> :
654 
		O
655 
		X
656 
</PRE>
657 
representing octal and hexadecimal literals respectively (decimal
658 
is the default), and:
659 
<PRE>
660 
	<I>lit-suffix</I> :
661 
		U
662 
		l
663 
		Ul
664 
		x
665 
		Ux
666 
</PRE>
667 
representing the <CODE>U</CODE>, <CODE>L</CODE>, <CODE>UL</CODE>,
668 
<CODE>LL</CODE> and <CODE>ULL</CODE> suffixes respectively.
669 
</P>
670 
<P>
671 
Target dependent integral promotion types are represented using
672 
<CODE>p</CODE>, so for example the promotion of <CODE>unsigned short</CODE>
673 
is represented as <CODE>pUs</CODE>.  Information on the other cases,
674 
where the promotion type is known, can be given in a command of the
675 
form:
676 
<PRE>
677 
	<I>promotion-command</I> :
678 
		P <I>type</I> : <I>type</I>
679 
</PRE>
680 
Thus the fact that the promotion of <CODE>short</CODE> is <CODE>int</CODE>
681 
would be expressed by the command <CODE>Ps:i</CODE>.
682 
</P>
683 
 
684 
<HR>
685 
<H3><A NAME="sort">2.4.6. Sorts</A></H3>
686 
<P>
687 
A <I>sort</I> in the symbol table dump corresponds to the sort of
688 
a token declared in the <A HREF="token.html#spec"><CODE>#pragma token</CODE>
689 
syntax</A>.  Expression tokens are represented as follows:
690 
<PRE>
691 
	<I>expression-sort</I> :
692 
		ZEL <I>type</I>
693 
		ZER <I>type</I>
694 
		ZEC <I>type</I>
695 
		ZN
696 
</PRE>
697 
corresponding to <CODE>lvalue</CODE>, <CODE>rvalue</CODE> and
698 
<CODE>const</CODE> <CODE>EXP</CODE> tokens of the given type, and
699 
<CODE>NAT</CODE> or <CODE>INTEGER</CODE> tokens, respectively. Statement
700 
tokens are represent by:
701 
<PRE>
702 
	<I>statement-sort</I> :
703 
		ZS
704 
</PRE>
705 
</P>
706 
<P>
707 
Type tokens are represented as follows:
708 
<PRE>
709 
	<I>type-sort</I> :
710 
		ZTO
711 
		ZTI
712 
		ZTF
713 
		ZTA
714 
		ZTP
715 
		ZTS
716 
		ZTU
717 
</PRE>
718 
corresponding to <CODE>TYPE</CODE>, <CODE>VARIETY</CODE>, <CODE>FLOAT</CODE>,
719 
<CODE>ARITHMETIC</CODE>, <CODE>SCALAR</CODE>, <CODE>STRUCT</CODE>
720 
or
721 
<CODE>CLASS</CODE>, and <CODE>UNION</CODE> token respectively.  There
722 
are corresponding <CODE>TAG</CODE> forms:
723 
<PRE>
724 
	<I>tag-type-sort</I> :
725 
		ZTTS
726 
		ZTTU
727 
</PRE>
728 
</P>
729 
<P>
730 
Member tokens are represented using:
731 
<PRE>
732 
	<I>member-sort</I> :
733 
		ZM <I>type</I> : <I>type-name</I>
734 
</PRE>
735 
where the first type gives the member type and the second gives the
736 
parent structure or union type.
737 
</P>
738 
<P>
739 
Procedure tokens can be represented using:
740 
<PRE>
741 
	<I>proc-sort</I> :
742 
		ZPG <I>parameter-list<SUB>opt</SUB></I> ; <I>parameter-list<SUB>opt</SUB></I> : <I>sort</I>
743 
		ZPS <I>parameter-list<SUB>opt</SUB></I> : <I>sort</I>
744 
</PRE>
745 
The first form corresponds to the more general form of <CODE>PROC</CODE>
746 
token, that expressed using <CODE>{ .... | .... }</CODE>, which has
747 
separate lists of bound and program parameters.  These token parameters
748 
will have previously been declared using the <CODE>XP</CODE> identifier
749 
key.  The second form corresponds to the case where the bound and
750 
program parameter lists are equal, that expressed as a <CODE>PROC</CODE>
751 
token using <CODE>( .... )</CODE>.  A more specialised version of
752 
this second form is a <CODE>FUNC</CODE> token, which is represented
753 
as:
754 
<PRE>
755 
	<I>func-sort</I> :
756 
		ZF <I>type</I>
757 
</PRE>
758 
</P>
759 
<P>
760 
As noted above, template parameters are represented by a <I>sort</I>.
761 
Template type parameters are represented by <CODE>ZTO</CODE>, while
762 
template expression parameters are represent by <CODE>ZEC</CODE>
763 
(recall that such parameters are always constant expressions).  The
764 
remaining case, template template parameters, can be represented as:
765 
<PRE>
766 
	<I>template-sort</I> :
767 
		ZTt <I>parameter-list<SUB>opt</SUB></I> :
768 
</PRE>
769 
</P>
770 
<P>
771 
Finally, the number of parameters in a macro definition is represented
772 
by a <I>sort</I> of the form:
773 
<PRE>
774 
	<I>macro-sort</I> :
775 
		ZUO
776 
		ZUF <I>number</I>
777 
</PRE>
778 
corresponding to a object-like macro and a function-like macro with
779 
the given number of parameters, respectively.
780 
</P>
781 
 
782 
<HR>
783 
<H3><A NAME="args">2.4.7. Token applications</A></H3>
784 
<P>
785 
Given an identifier representing a <CODE>PROC</CODE> token or a template,
786 
an application of that token or an instance of that template can be
787 
represented using:
788 
<PRE>
789 
	<I>token-application</I> :
790 
		T <I>identifier</I> , <I>token-argument-list</I> :
791 
</PRE>
792 
where the token or template arguments are given by:
793 
<PRE>
794 
	<I>token-argument-list</I> :
795 
		<I>token-argument</I>
796 
		<I>token-argument</I> , <I>token-argument-list</I>
797 
</PRE>
798 
Note that the case where there are no arguments is generally just
799 
represented by <I>identifier</I>; this case is specified separately
800 
in the rest of the grammar.
801 
</P>
802 
<P>
803 
A <I>token-argument</I> can represent a value of any of the sorts
804 
listed above: expressions, integer constants, statements, types, members,
805 
functions and templates.  These are given respectively by:
806 
<PRE>
807 
	<I>token-argument</I> :
808 
		E <I>expression</I>
809 
		N <I>nat</I>
810 
		S <I>statement</I>
811 
		T <I>type</I>
812 
		M <I>member</I>
813 
		F <I>identifier</I>
814 
		C <I>identifier</I>
815 
</PRE>
816 
where:
817 
<PRE>
818 
	<I>expression</I> :
819 
		<I>nat</I>
820 
 
821 
	<I>statement</I> :
822 
		<I>expression</I>
823 
 
824 
	<I>member</I> :
825 
		<I>identifier</I>
826 
		<I>string</I>
827 
</PRE>
828 
</P>
829 
 
830 
<HR>
831 
<H3><A NAME="error">2.4.8. Errors</A></H3>
832 
<P>
833 
Each error in the C++ <A HREF="error.html">error catalogue</A> is
834 
represented by a number.  These numbers happen to correspond to the
835 
position of the error within the catalogue, but in general this need
836 
not be the case.  The first use of each error introduces the error
837 
number by associating it with a <I>string</I> giving the error name.
838 
This has the form <CODE>cpp.</CODE><I>error</I> where <I>error</I>
839 
gives an error name from the C++ (<CODE>cpp</CODE>) error catalogue.
840 
Thus:
841 
<PRE>
842 
	<I>error-name</I> :
843 
		<I>number</I> = <I>string</I>
844 
		<I>number</I>
845 
</PRE>
846 
</P>
847 
<P>
848 
Each error message written to the symbol table dump has the form:
849 
<PRE>
850 
	<I>error-command</I> :
851 
		ES <I>location error-info</I>
852 
		EW <I>location error-info</I>
853 
		EI <I>location error-info</I>
854 
		EF <I>location error-info</I>
855 
		EC <I>error-info</I>
856 
		EA <I>error-argument</I>
857 
</PRE>
858 
denoting constraint errors, warnings, internal errors, fatal errors,
859 
continuation errors and error arguments respectively.  Note that an
860 
error message may consist of several components; the initial error
861 
plus a number of continuation errors.  Each error message may also
862 
have a number of error argument associated with it.  This error information
863 
is given by:
864 
<PRE>
865 
	<I>error-info</I> :
866 
		<I>error-name number number</I>
867 
</PRE>
868 
where the first <I>number</I> gives the number of error arguments
869 
which should be read, and the second is nonzero to indicate that a
870 
continuation error should be read.
871 
</P>
872 
<P>
873 
Each error argument has one of the forms:
874 
<PRE>
875 
	<I>error-argument</I> :
876 
		B <I>base-number</I>
877 
		C <I>scope-identifier</I>
878 
		E <I>expression</I>
879 
		H <I>identifier-name</I>
880 
		I <I>identifier</I>
881 
		L <I>location</I>
882 
		N <I>nat</I>
883 
		S <I>string</I>
884 
		T <I>type</I>
885 
		V <I>number</I>
886 
		V - <I>number</I>
887 
</PRE>
888 
corresponding to the various syntactic categories described above.
889 
Note that a <I>location</I> error argument, while expressed relative
890 
to the
891 
<A HREF="#crt_loc">current file location</A>, does not change this
892 
location.
893 
</P>
894 
 
895 
<HR>
896 
<H3><A NAME="file">2.4.9. File inclusions</A></H3>
897 
<P>
898 
It is possible to include information on header files within the symbol
899 
table dump.  Firstly a number is associated with each directory on
900 
the <CODE>#include</CODE> search path:
901 
<PRE>
902 
	<I>path-command</I> :
903 
		FD <I>number</I> = <I>string string<SUB>opt</SUB></I>
904 
</PRE>
905 
The first <I>string</I> gives the directory pathname; the second,
906 
if present, gives the associated directory name as specified in the
907 
<A HREF="man.html#directory"><CODE>-N</CODE> command-line option</A>.
908 
</P>
909 
<P>
910 
Now the start and end of each file are marked using:
911 
<PRE>
912 
	<I>file-command</I> :
913 
		FS <I>location directory</I>
914 
		FE <I>location</I>
915 
</PRE>
916 
where <I>directory</I> gives the number of the directory in the search
917 
path where the file was found, or <CODE>*</CODE> if the file was found
918 
by other means.  It is worth noting that if, for example, a function
919 
definition is the last item in a file, the <CODE>FE</CODE> command
920 
will appear in the symbol table dump before the <CODE>QFE</CODE> command
921 
for the end of the function definition.  This is because lexical analysis,
922 
where the end of file is detected, takes place before parsing, where
923 
the end of function is detected.
924 
</P>
925 
<P>
926 
A <CODE>#include</CODE> directive, whether explicit or implicit, can
927 
be represented using:
928 
<PRE>
929 
	<I>include-command</I> :
930 
		FIA <I>location string</I>
931 
		FIQ <I>location string</I>
932 
		FIN <I>location string</I>
933 
		FIS <I>location string</I>
934 
		FIE <I>location string</I>
935 
		FIR <I>location</I>
936 
</PRE>
937 
the first three corresponding to header names of the forms
938 
<CODE>&lt;....&gt;</CODE>, <CODE>&quot;....&quot;</CODE> and <CODE>[....]</CODE>
939 
respectively, the next two corresponding to <A HREF="man.html#start-up">start-up
940 
</A>
941 
and <A HREF="man.html#end-up">end-up</A> files, and the final form
942 
being used to resume the original file after the <CODE>#include</CODE>
943 
directive has been processed.
944 
</P>
945 
 
946 
<HR>
947 
<H3><A NAME="string">2.4.10. String literals</A></H3>
948 
<P>
949 
It is possible to dump information on string literals to the symbol
950 
table dump file using the commands:
951 
<PRE>
952 
	<I>string-command</I> :
953 
		A <I>location string</I>
954 
		AC <I>location string</I>
955 
		AL <I>location string</I>
956 
		ACL <I>location string</I>
957 
</PRE>
958 
representing string literals, character literals, wide string literals
959 
and wide character literals respectively.  The given <I>string</I>
960 
gives the string text.
961 
</P>
962 
 
963 
<HR>
964 
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
965 
Copyright &copy; 1998.</I></P>
966 
</BODY>
967 
</HTML>