| 2 |
7u83 |
1 |
<!-- Crown Copyright (c) 1998 -->
|
|
|
2 |
<HTML>
|
|
|
3 |
<HEAD>
|
|
|
4 |
<TITLE>tcc User's Guide: Miscellaneous Topics</TITLE>
|
|
|
5 |
</HEAD>
|
|
|
6 |
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
|
|
|
7 |
<A NAME=S43>
|
|
|
8 |
<H1>tcc User's Guide</H1>
|
|
|
9 |
<H3>January 1998</H3>
|
|
|
10 |
<A HREF="tcc8.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
|
|
|
11 |
<A HREF="tcc6.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
|
|
|
12 |
<A HREF="tcc1.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="#S44"><B>6.1</B> - Intermodular Checks</A><DD>
|
|
|
19 |
<DT><A HREF="#S45"><B>6.2</B> - Debugging and Profiling</A><DD>
|
|
|
20 |
<DT><A HREF="#S46"><B>6.3</B> - The System Environment</A><DD>
|
|
|
21 |
<DT><A HREF="#S47"><B>6.4</B> - The Temporary Directory</A><DD>
|
|
|
22 |
<DT><A HREF="#S48"><B>6.5</B> - The tcc Option Interpreter</A>
|
|
|
23 |
<DD>
|
|
|
24 |
</DL>
|
|
|
25 |
|
|
|
26 |
<HR>
|
|
|
27 |
<H1>6. Miscellaneous Topics</H1>
|
|
|
28 |
In this section we draw together a number of miscellaneous topics
|
|
|
29 |
not so far covered.<P>
|
|
|
30 |
<A NAME=S44>
|
|
|
31 |
<HR><H2>6.1. Intermodular Checks</H2>
|
|
|
32 |
All of the extra compiler checks described in section 5.1.3</A> refer
|
|
|
33 |
to a single C source file, however <CODE>tcc</CODE> also has support
|
|
|
34 |
for a number of intermodular checks. These checks are enabled by means
|
|
|
35 |
of the <B>-im</B> command-line option. This causes the producer to
|
|
|
36 |
create for each C source file, in addition to its TDF capsule output
|
|
|
37 |
file, a second output file, called a C spec file, containing a description
|
|
|
38 |
of the C objects declared in that file. This C spec file is kept associated
|
|
|
39 |
with the target independent TDF as it is transformed to a target dependent
|
|
|
40 |
capsule, an assembly source file, and a binary object file. When these
|
|
|
41 |
binary object files are linked then the associated C spec files are
|
|
|
42 |
also linked using the C spec linker, <CODE>spec_linker</CODE>, into
|
|
|
43 |
a single C spec file. This file is named <CODE>a.k</CODE> by default.
|
|
|
44 |
It is this linking process which constitutes the intermodular checking
|
|
|
45 |
(in fact <CODE>spec_linker</CODE> may also be invoked at the TDF merging
|
|
|
46 |
level when the <B>-M</B> option is used).<P>
|
|
|
47 |
When intermodular checks are specified, <CODE>tcc</CODE> will also
|
|
|
48 |
recognise input files with a <CODE>.k</CODE> suffix as C spec files
|
|
|
49 |
and pass them to the C spec linker.<P>
|
|
|
50 |
The nature of the association between a C spec file and its binary
|
|
|
51 |
object file needs discussion. While these files are internal to a
|
|
|
52 |
single call of <CODE>tcc</CODE> it can keep track of the association,
|
|
|
53 |
however if the compilation is halted before linking it needs to preserve
|
|
|
54 |
this association. For example in:<P>
|
|
|
55 |
<PRE>
|
|
|
56 |
> tcc -im -c a.c
|
|
|
57 |
</PRE>
|
|
|
58 |
the binary object file <CODE>a.o</CODE> and the C spec file <CODE>a.k</CODE>
|
|
|
59 |
need to be kept together. This is done by forming them into a single
|
|
|
60 |
archive file named <CODE>a.o</CODE>. When <CODE>a.o</CODE> is subsequently
|
|
|
61 |
linked, <CODE>tcc</CODE> recognises that it is an archive and splits
|
|
|
62 |
it into its two components, one of which it passes to the system linker,
|
|
|
63 |
and one to the C spec linker.<P>
|
|
|
64 |
Intermodular checking is described in more detail in [3]. In <CODE>tchk</CODE>
|
|
|
65 |
intermodular checking is on by default, but may be switched off using
|
|
|
66 |
<B>-im0</B>.<P>
|
|
|
67 |
<A NAME=S45>
|
|
|
68 |
<HR><H2>6.2. Debugging and Profiling</H2>
|
|
|
69 |
<CODE>tcc</CODE> supports options for both symbolic debugging using
|
|
|
70 |
the target machine's default debugger, and profiling using <CODE>prof</CODE>
|
|
|
71 |
on those machines which have it.<P>
|
|
|
72 |
The <B>-g</B> command-line option causes the producer to output extra
|
|
|
73 |
debugging information in its output TDF capsule, and the TDF translator
|
|
|
74 |
to translate this information into the appropriate assembler directives
|
|
|
75 |
for its supported debugger (for details of which debuggers are supported
|
|
|
76 |
by which translators, consult the appropriate manual pages). For the
|
|
|
77 |
translator to have all the diagnostic information it requires, not
|
|
|
78 |
only the TDF capsules output by the producer, but also those linked
|
|
|
79 |
in by the TDF linker from the TDF libraries, need to contain this
|
|
|
80 |
debugging information. This is ensured for the standard TDF libraries
|
|
|
81 |
by having two versions of each library, one containing diagnostics
|
|
|
82 |
and one not. By default the environmental identifier <CODE>LINK</CODE>,
|
|
|
83 |
which gives the directories which the TDF linker should search, is
|
|
|
84 |
set so that the non-diagnostic versions are found. However the <B>-g</B>
|
|
|
85 |
option modifies <CODE>LINK</CODE> so that the diagnostic versions
|
|
|
86 |
are found first.<P>
|
|
|
87 |
Depending on the target machine, the <B>-g</B> option may also need
|
|
|
88 |
to modify the behaviour of the system assembler and the system linker.
|
|
|
89 |
Like all potentially target dependent options, <B>-g</B> is implemented
|
|
|
90 |
by means of a standard environment, in this case <CODE>tcc_diag</CODE>.<P>
|
|
|
91 |
The <B>-p</B> option is likewise implemented by means of a standard
|
|
|
92 |
environment, <CODE>tcc_prof</CODE>. It causes the producer to output
|
|
|
93 |
extra information on the names of statically declared objects, and
|
|
|
94 |
the TDF translator to output assembler directives which enable <CODE>prof</CODE>
|
|
|
95 |
to profile the number of calls to each procedure (including static
|
|
|
96 |
procedures). The behaviour of the system assembler and system linker
|
|
|
97 |
may also be modified by <B>-p</B>, depending on the target machine.<P>
|
|
|
98 |
<A NAME=S46>
|
|
|
99 |
<HR><H2>6.3. The System Environment</H2>
|
|
|
100 |
In section 4.3</A> we discussed how <CODE>tcc</CODE> environments
|
|
|
101 |
can be used to specify APIs. There is one API environment however
|
|
|
102 |
which is so exceptional that it needs to be treated separately. This
|
|
|
103 |
is the <CODE>system</CODE> environment, which specifies that <CODE>tcc</CODE>
|
|
|
104 |
should emulate <CODE>cc</CODE> on the machine on which it is being
|
|
|
105 |
run. The <CODE>system</CODE> environment specifies that <CODE>tcc</CODE>
|
|
|
106 |
should use the system headers directory, <CODE>/usr/include</CODE>,
|
|
|
107 |
as its default include file directory, and should define all the machine
|
|
|
108 |
dependent macros which are built into <CODE>cc</CODE>. It will also
|
|
|
109 |
specify the 32-bit portability table on 32-bit machines.<P>
|
|
|
110 |
Despite the differences from the normal API environments, the <CODE>system
|
|
|
111 |
</CODE> environment is indeed specifying an API, namely the system
|
|
|
112 |
headers and libraries on the host machine. This means that the <CODE>.j</CODE>
|
|
|
113 |
files produced when using this environment are only "target independent"
|
|
|
114 |
in the sense that they can be ported successfully to machines which
|
|
|
115 |
have the exactly the same system headers and predefined macros.<P>
|
|
|
116 |
Using the system headers is fraught with difficulties. In particular,
|
|
|
117 |
they tend to be very <CODE>cc</CODE>-specific. It is often necessary
|
|
|
118 |
to use the <B>-not_ansi</B> and <B>-nepc</B> options together with
|
|
|
119 |
<B>-Ysystem</B> merely to negotiate the system headers. Even then,
|
|
|
120 |
<CODE>tcc</CODE> may still reject some constructs. Of course, the
|
|
|
121 |
number of problems encountered will vary considerably between different
|
|
|
122 |
machines.<P>
|
|
|
123 |
To conclude, the <CODE>system</CODE> environment is at best only suitable
|
|
|
124 |
for experimental compilation. There are also potential problems involved
|
|
|
125 |
with its use. It should therefore be used with care.<P>
|
|
|
126 |
<A NAME=S47>
|
|
|
127 |
<HR><H2>6.4. The Temporary Directory</H2>
|
|
|
128 |
As we have said, <CODE>tcc</CODE> creates a temporary directory in
|
|
|
129 |
which to put all the intermediate files which are created, but are
|
|
|
130 |
not to be preserved. By default, these intermediate files are left
|
|
|
131 |
in the temporary directory until the end of the compilation, when
|
|
|
132 |
the temporary directory is removed. However, if disk space is short,
|
|
|
133 |
or a particularly large compilation is taking place, the <B>-tidy</B>
|
|
|
134 |
command-line option may be appropriate. This causes <CODE>tcc</CODE>
|
|
|
135 |
to remove each unwanted intermediate file immediately when it is no
|
|
|
136 |
longer required.<P>
|
|
|
137 |
The name of the temporary directory created by <CODE>tcc</CODE> to
|
|
|
138 |
store the intermediate files is generated by the system library routine
|
|
|
139 |
<CODE>tempnam</CODE>. It takes the form <CODE>TEMP/tcc????</CODE>,
|
|
|
140 |
where <CODE>TEMP</CODE> is the main <CODE>tcc</CODE> temporary directory,
|
|
|
141 |
and <CODE>????</CODE> is an automatically generated unique suffix.
|
|
|
142 |
There are three methods of specifying <CODE>TEMP</CODE>, listed in
|
|
|
143 |
order of increasing precedence:<P>
|
|
|
144 |
<UL>
|
|
|
145 |
<LI>by the <CODE>TEMP</CODE> environmental identifier (usually in
|
|
|
146 |
the <CODE>default</CODE> environment),<P>
|
|
|
147 |
<LI>by the <B>-temp</B> <I>dir</I> command-line option,<P>
|
|
|
148 |
<LI>by the <CODE>TMPDIR</CODE> system variable.<P>
|
|
|
149 |
</UL>
|
|
|
150 |
Normally <CODE>TEMP</CODE> will be a normal temporary directory, <CODE>/tmp
|
|
|
151 |
</CODE> or <CODE>/usr/tmp</CODE> for example, but any directory to
|
|
|
152 |
which the user has write permission may be used. In general, the more
|
|
|
153 |
spare disk space which is available in <CODE>TEMP</CODE>, the better.<P>
|
|
|
154 |
<A NAME=S48>
|
|
|
155 |
<HR><H2>6.5. The tcc Option Interpreter</H2>
|
|
|
156 |
All <CODE>tcc</CODE> command-line options and environmental directives
|
|
|
157 |
are actually processed by the same method, namely the <CODE>tcc</CODE>
|
|
|
158 |
option interpreter. A simple pattern matching algorithm is applied
|
|
|
159 |
to the input and, if a match is found, the corresponding instructions
|
|
|
160 |
are sent to the low-level option interpreter. The command-line option
|
|
|
161 |
<B>--</B><I>str</I><B>,</B> ... causes <I>str</I> to be passed directly
|
|
|
162 |
to the option interpreter. This is intended primarily to help in debugging
|
|
|
163 |
<CODE>tcc</CODE> and not for use by the general user. However, if
|
|
|
164 |
you are interested, <B>--1DB</B> is a good place to start.<P>
|
|
|
165 |
<!-- FM pgf ignored -->
|
|
|
166 |
<PRE>
|
|
|
167 |
[1] <I>TDF and Portability</I>, DRA, 1994.
|
|
|
168 |
[2] <I>The C to TDF Producer</I>, DRA, 1993.
|
|
|
169 |
[3] <I>The TenDRA Static Checker</I>, DRA, 1994.
|
|
|
170 |
[4] <I>The TDF Notation Compiler</I>, DRA, 1994.
|
|
|
171 |
|
|
|
172 |
</PRE>
|
|
|
173 |
<HR>
|
|
|
174 |
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
|
|
|
175 |
Copyright © 1998.</I></P>
|
|
|
176 |
</BODY>
|
|
|
177 |
</HTML>
|