Blame | Last modification | View Log | RSS feed
<!-- Crown Copyright (c) 1998 -->
<HTML>
<HEAD>
<TITLE>tcc User's Guide: Miscellaneous Topics</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
<A NAME=S43>
<H1>tcc User's Guide</H1>
<H3>January 1998</H3>
<A HREF="tcc8.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
<A HREF="tcc6.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
<A HREF="tcc1.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="#S44"><B>6.1</B> - Intermodular Checks</A><DD>
<DT><A HREF="#S45"><B>6.2</B> - Debugging and Profiling</A><DD>
<DT><A HREF="#S46"><B>6.3</B> - The System Environment</A><DD>
<DT><A HREF="#S47"><B>6.4</B> - The Temporary Directory</A><DD>
<DT><A HREF="#S48"><B>6.5</B> - The tcc Option Interpreter</A>
<DD>
</DL>
<HR>
<H1>6. Miscellaneous Topics</H1>
In this section we draw together a number of miscellaneous topics
not so far covered.<P>
<A NAME=S44>
<HR><H2>6.1. Intermodular Checks</H2>
All of the extra compiler checks described in section 5.1.3</A> refer
to a single C source file, however <CODE>tcc</CODE> also has support
for a number of intermodular checks. These checks are enabled by means
of the <B>-im</B> command-line option. This causes the producer to
create for each C source file, in addition to its TDF capsule output
file, a second output file, called a C spec file, containing a description
of the C objects declared in that file. This C spec file is kept associated
with the target independent TDF as it is transformed to a target dependent
capsule, an assembly source file, and a binary object file. When these
binary object files are linked then the associated C spec files are
also linked using the C spec linker, <CODE>spec_linker</CODE>, into
a single C spec file. This file is named <CODE>a.k</CODE> by default.
It is this linking process which constitutes the intermodular checking
(in fact <CODE>spec_linker</CODE> may also be invoked at the TDF merging
level when the <B>-M</B> option is used).<P>
When intermodular checks are specified, <CODE>tcc</CODE> will also
recognise input files with a <CODE>.k</CODE> suffix as C spec files
and pass them to the C spec linker.<P>
The nature of the association between a C spec file and its binary
object file needs discussion. While these files are internal to a
single call of <CODE>tcc</CODE> it can keep track of the association,
however if the compilation is halted before linking it needs to preserve
this association. For example in:<P>
<PRE>
> tcc -im -c a.c
</PRE>
the binary object file <CODE>a.o</CODE> and the C spec file <CODE>a.k</CODE>
need to be kept together. This is done by forming them into a single
archive file named <CODE>a.o</CODE>. When <CODE>a.o</CODE> is subsequently
linked, <CODE>tcc</CODE> recognises that it is an archive and splits
it into its two components, one of which it passes to the system linker,
and one to the C spec linker.<P>
Intermodular checking is described in more detail in [3]. In <CODE>tchk</CODE>
intermodular checking is on by default, but may be switched off using
<B>-im0</B>.<P>
<A NAME=S45>
<HR><H2>6.2. Debugging and Profiling</H2>
<CODE>tcc</CODE> supports options for both symbolic debugging using
the target machine's default debugger, and profiling using <CODE>prof</CODE>
on those machines which have it.<P>
The <B>-g</B> command-line option causes the producer to output extra
debugging information in its output TDF capsule, and the TDF translator
to translate this information into the appropriate assembler directives
for its supported debugger (for details of which debuggers are supported
by which translators, consult the appropriate manual pages). For the
translator to have all the diagnostic information it requires, not
only the TDF capsules output by the producer, but also those linked
in by the TDF linker from the TDF libraries, need to contain this
debugging information. This is ensured for the standard TDF libraries
by having two versions of each library, one containing diagnostics
and one not. By default the environmental identifier <CODE>LINK</CODE>,
which gives the directories which the TDF linker should search, is
set so that the non-diagnostic versions are found. However the <B>-g</B>
option modifies <CODE>LINK</CODE> so that the diagnostic versions
are found first.<P>
Depending on the target machine, the <B>-g</B> option may also need
to modify the behaviour of the system assembler and the system linker.
Like all potentially target dependent options, <B>-g</B> is implemented
by means of a standard environment, in this case <CODE>tcc_diag</CODE>.<P>
The <B>-p</B> option is likewise implemented by means of a standard
environment, <CODE>tcc_prof</CODE>. It causes the producer to output
extra information on the names of statically declared objects, and
the TDF translator to output assembler directives which enable <CODE>prof</CODE>
to profile the number of calls to each procedure (including static
procedures). The behaviour of the system assembler and system linker
may also be modified by <B>-p</B>, depending on the target machine.<P>
<A NAME=S46>
<HR><H2>6.3. The System Environment</H2>
In section 4.3</A> we discussed how <CODE>tcc</CODE> environments
can be used to specify APIs. There is one API environment however
which is so exceptional that it needs to be treated separately. This
is the <CODE>system</CODE> environment, which specifies that <CODE>tcc</CODE>
should emulate <CODE>cc</CODE> on the machine on which it is being
run. The <CODE>system</CODE> environment specifies that <CODE>tcc</CODE>
should use the system headers directory, <CODE>/usr/include</CODE>,
as its default include file directory, and should define all the machine
dependent macros which are built into <CODE>cc</CODE>. It will also
specify the 32-bit portability table on 32-bit machines.<P>
Despite the differences from the normal API environments, the <CODE>system
</CODE> environment is indeed specifying an API, namely the system
headers and libraries on the host machine. This means that the <CODE>.j</CODE>
files produced when using this environment are only "target independent"
in the sense that they can be ported successfully to machines which
have the exactly the same system headers and predefined macros.<P>
Using the system headers is fraught with difficulties. In particular,
they tend to be very <CODE>cc</CODE>-specific. It is often necessary
to use the <B>-not_ansi</B> and <B>-nepc</B> options together with
<B>-Ysystem</B> merely to negotiate the system headers. Even then,
<CODE>tcc</CODE> may still reject some constructs. Of course, the
number of problems encountered will vary considerably between different
machines.<P>
To conclude, the <CODE>system</CODE> environment is at best only suitable
for experimental compilation. There are also potential problems involved
with its use. It should therefore be used with care.<P>
<A NAME=S47>
<HR><H2>6.4. The Temporary Directory</H2>
As we have said, <CODE>tcc</CODE> creates a temporary directory in
which to put all the intermediate files which are created, but are
not to be preserved. By default, these intermediate files are left
in the temporary directory until the end of the compilation, when
the temporary directory is removed. However, if disk space is short,
or a particularly large compilation is taking place, the <B>-tidy</B>
command-line option may be appropriate. This causes <CODE>tcc</CODE>
to remove each unwanted intermediate file immediately when it is no
longer required.<P>
The name of the temporary directory created by <CODE>tcc</CODE> to
store the intermediate files is generated by the system library routine
<CODE>tempnam</CODE>. It takes the form <CODE>TEMP/tcc????</CODE>,
where <CODE>TEMP</CODE> is the main <CODE>tcc</CODE> temporary directory,
and <CODE>????</CODE> is an automatically generated unique suffix.
There are three methods of specifying <CODE>TEMP</CODE>, listed in
order of increasing precedence:<P>
<UL>
<LI>by the <CODE>TEMP</CODE> environmental identifier (usually in
the <CODE>default</CODE> environment),<P>
<LI>by the <B>-temp</B> <I>dir</I> command-line option,<P>
<LI>by the <CODE>TMPDIR</CODE> system variable.<P>
</UL>
Normally <CODE>TEMP</CODE> will be a normal temporary directory, <CODE>/tmp
</CODE> or <CODE>/usr/tmp</CODE> for example, but any directory to
which the user has write permission may be used. In general, the more
spare disk space which is available in <CODE>TEMP</CODE>, the better.<P>
<A NAME=S48>
<HR><H2>6.5. The tcc Option Interpreter</H2>
All <CODE>tcc</CODE> command-line options and environmental directives
are actually processed by the same method, namely the <CODE>tcc</CODE>
option interpreter. A simple pattern matching algorithm is applied
to the input and, if a match is found, the corresponding instructions
are sent to the low-level option interpreter. The command-line option
<B>--</B><I>str</I><B>,</B> ... causes <I>str</I> to be passed directly
to the option interpreter. This is intended primarily to help in debugging
<CODE>tcc</CODE> and not for use by the general user. However, if
you are interested, <B>--1DB</B> is a good place to start.<P>
<!-- FM pgf ignored -->
<PRE>
[1] <I>TDF and Portability</I>, DRA, 1994.
[2] <I>The C to TDF Producer</I>, DRA, 1993.
[3] <I>The TenDRA Static Checker</I>, DRA, 1994.
[4] <I>The TDF Notation Compiler</I>, DRA, 1994.
</PRE>
<HR>
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
Copyright © 1998.</I></P>
</BODY>
</HTML>