6.1. Intermodular Checks
All of the extra compiler checks described in section 5.1.3 refer
to a single C source file, however tcc also has support
for a number of intermodular checks. These checks are enabled by means
of the -im 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, spec_linker, into
a single C spec file. This file is named a.k by default.
It is this linking process which constitutes the intermodular checking
(in fact spec_linker may also be invoked at the TDF merging
level when the -M option is used).
When intermodular checks are specified, tcc will also
recognise input files with a .k suffix as C spec files
and pass them to the C spec linker.
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 tcc it can keep track of the association,
however if the compilation is halted before linking it needs to preserve
this association. For example in:
> tcc -im -c a.cthe binary object file
a.o and the C spec file a.k
need to be kept together. This is done by forming them into a single
archive file named a.o. When a.o is subsequently
linked, tcc 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.
Intermodular checking is described in more detail in [3]. In tchk
intermodular checking is on by default, but may be switched off using
-im0.
The -g 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
Depending on the target machine, the -g option may also need
to modify the behaviour of the system assembler and the system linker.
Like all potentially target dependent options, -g is implemented
by means of a standard environment, in this case
The -p option is likewise implemented by means of a standard
environment,
Despite the differences from the normal API environments, the
Using the system headers is fraught with difficulties. In particular,
they tend to be very
To conclude, the
The name of the temporary directory created by
Part of the TenDRA Web.6.2. Debugging and Profiling
tcc supports options for both symbolic debugging using
the target machine's default debugger, and profiling using prof
on those machines which have it.LINK,
which gives the directories which the TDF linker should search, is
set so that the non-diagnostic versions are found. However the -g
option modifies LINK so that the diagnostic versions
are found first.tcc_diag.tcc_prof. 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 prof
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 -p, depending on the target machine.6.3. The System Environment
In section 4.3 we discussed how tcc 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 system environment, which specifies that tcc
should emulate cc on the machine on which it is being
run. The system environment specifies that tcc
should use the system headers directory, /usr/include,
as its default include file directory, and should define all the machine
dependent macros which are built into cc. It will also
specify the 32-bit portability table on 32-bit machines.system
environment is indeed specifying an API, namely the system
headers and libraries on the host machine. This means that the .j
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.cc-specific. It is often necessary
to use the -not_ansi and -nepc options together with
-Ysystem merely to negotiate the system headers. Even then,
tcc may still reject some constructs. Of course, the
number of problems encountered will vary considerably between different
machines.system 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.6.4. The Temporary Directory
As we have said, tcc 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 -tidy
command-line option may be appropriate. This causes tcc
to remove each unwanted intermediate file immediately when it is no
longer required.tcc to
store the intermediate files is generated by the system library routine
tempnam. It takes the form TEMP/tcc????,
where TEMP is the main tcc temporary directory,
and ???? is an automatically generated unique suffix.
There are three methods of specifying TEMP, listed in
order of increasing precedence:
Normally TEMP environmental identifier (usually in
the default environment),TMPDIR system variable.TEMP will be a normal temporary directory, /tmp
or /usr/tmp 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 TEMP, the better.6.5. The tcc Option Interpreter
All tcc command-line options and environmental directives
are actually processed by the same method, namely the tcc
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
--str, ... causes str to be passed directly
to the option interpreter. This is intended primarily to help in debugging
tcc and not for use by the general user. However, if
you are interested, --1DB is a good place to start.
[1] TDF and Portability, DRA, 1994.
[2] The C to TDF Producer, DRA, 1993.
[3] The TenDRA Static Checker, DRA, 1994.
[4] The TDF Notation Compiler, DRA, 1994.
Crown
Copyright © 1998.