tcc identifies the file type of the input files it is
passed by means of their file suffix. The recognised file suffixes
are as follows:
Each file type is assigned an identifying lter. debugger, and profiling using prof
on those machines which have it.
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 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.
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 tcc_diag.
The -p option is likewise implemented by means of a standard
environment, 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.
Despite the differences from the normal API environments, the 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.
Using the system headers is fraught with difficulties. In particular,
they tend to be very 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.
To conclude, the 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.