| 1 |
4 |
hellwig |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
| 2 |
|
|
<html>
|
| 3 |
|
|
|
| 4 |
|
|
<head>
|
| 5 |
|
|
<link HREF="mailto:drh@cs.princeton.edu" REV="made" TITLE="David R. Hanson">
|
| 6 |
|
|
<title>Installing lcc</title>
|
| 7 |
|
|
</head>
|
| 8 |
|
|
|
| 9 |
|
|
<body>
|
| 10 |
|
|
|
| 11 |
|
|
<h1>Installing lcc</h1>
|
| 12 |
|
|
|
| 13 |
|
|
<p ALIGN="LEFT"><strong><a HREF="http://www.research.microsoft.com/~cwfraser/">Christopher
|
| 14 |
|
|
W. Fraser</a> and <a HREF="http://www.research.microsoft.com/~drh/">David R. Hanson</a>, <a
|
| 15 |
|
|
HREF="http://www.research.microsoft.com/">Microsoft Research</a></strong><br>
|
| 16 |
|
|
September 2002</p>
|
| 17 |
|
|
|
| 18 |
|
|
<h2>Contents</h2>
|
| 19 |
|
|
|
| 20 |
|
|
<dir>
|
| 21 |
|
|
<li><a HREF="#intro">Introduction</a></li>
|
| 22 |
|
|
<li><a HREF="#unix">Installation on UNIX</a></li>
|
| 23 |
|
|
<li><a HREF="#driver">Building the Driver</a></li>
|
| 24 |
|
|
<li><a HREF="#rcc">Building the Compiler and Accessories</a></li>
|
| 25 |
|
|
<li><a HREF="#win32">Installation on Windows</a></li>
|
| 26 |
|
|
<li><a HREF="#bugs">Reporting Bugs</a></li>
|
| 27 |
|
|
<li><a HREF="#mailinglist">Keeping in Touch</a></li>
|
| 28 |
|
|
</dir>
|
| 29 |
|
|
|
| 30 |
|
|
<h2><a NAME="intro">Introduction</a></h2>
|
| 31 |
|
|
|
| 32 |
|
|
<p><a HREF="http://www.cs.princeton.edu/software/lcc/">lcc</a> is the ANSI C compiler
|
| 33 |
|
|
described in our book <cite>A Retargetable C Compiler: Design and Implementation</cite>
|
| 34 |
|
|
(Addison-Wesley, 1995, ISBN 0-8053-1670-1).</p>
|
| 35 |
|
|
|
| 36 |
|
|
<p>If you're installing lcc on a UNIX system, read the remainder of this section and
|
| 37 |
|
|
continue with the next section. If you're installing lcc on a Windows system, you should read the rest of this section, the following three sections, and the <a
|
| 38 |
|
|
HREF="#win32">Windows</a> section.</p>
|
| 39 |
|
|
|
| 40 |
|
|
<p>Extract the distribution into its own directory. All non-absolute paths below are
|
| 41 |
|
|
relative to this directory. The distribution holds the following subdirectories.</p>
|
| 42 |
|
|
|
| 43 |
|
|
<blockquote>
|
| 44 |
|
|
<table BORDER="0" CELLPADDING="1" CELLSPACING="1" WIDTH="80%">
|
| 45 |
|
|
<tr>
|
| 46 |
|
|
<td><a HREF="../src"><code>src</code></a></td>
|
| 47 |
|
|
<td></td>
|
| 48 |
|
|
<td>source code</td>
|
| 49 |
|
|
</tr>
|
| 50 |
|
|
<tr>
|
| 51 |
|
|
<td><a HREF="../etc"><code>etc</code></a></td>
|
| 52 |
|
|
<td></td>
|
| 53 |
|
|
<td>driver, accessories</td>
|
| 54 |
|
|
</tr>
|
| 55 |
|
|
<tr>
|
| 56 |
|
|
<td><a HREF="../lib"><code>lib</code></a></td>
|
| 57 |
|
|
<td></td>
|
| 58 |
|
|
<td>runtime library source code</td>
|
| 59 |
|
|
</tr>
|
| 60 |
|
|
<tr>
|
| 61 |
|
|
<td><a HREF="../cpp"><code>cpp</code></a></td>
|
| 62 |
|
|
<td></td>
|
| 63 |
|
|
<td>preprocessor source code</td>
|
| 64 |
|
|
</tr>
|
| 65 |
|
|
<tr>
|
| 66 |
|
|
<td><a HREF="../lburg"><code>lburg</code></a></td>
|
| 67 |
|
|
<td></td>
|
| 68 |
|
|
<td>code-generator generator source code</td>
|
| 69 |
|
|
</tr>
|
| 70 |
|
|
<tr>
|
| 71 |
|
|
<td><a HREF="../doc"><code>doc</code></a></td>
|
| 72 |
|
|
<td></td>
|
| 73 |
|
|
<td>this document, man pages</td>
|
| 74 |
|
|
</tr>
|
| 75 |
|
|
<tr>
|
| 76 |
|
|
<td><code><a HREF="../include">include</a>/*/*</code></td>
|
| 77 |
|
|
<td></td>
|
| 78 |
|
|
<td>include files</td>
|
| 79 |
|
|
</tr>
|
| 80 |
|
|
<tr>
|
| 81 |
|
|
<td><a HREF="../tst"><code>tst</code></a></td>
|
| 82 |
|
|
<td></td>
|
| 83 |
|
|
<td>test suite</td>
|
| 84 |
|
|
</tr>
|
| 85 |
|
|
<tr>
|
| 86 |
|
|
<td><code><a HREF="../alpha">alpha</a>/*/tst</code></td>
|
| 87 |
|
|
<td></td>
|
| 88 |
|
|
<td>ALPHA test outputs</td>
|
| 89 |
|
|
</tr>
|
| 90 |
|
|
<tr>
|
| 91 |
|
|
<td><code><a HREF="../mips">mips</a>/*/tst</code></td>
|
| 92 |
|
|
<td></td>
|
| 93 |
|
|
<td>MIPS test outputs</td>
|
| 94 |
|
|
</tr>
|
| 95 |
|
|
<tr>
|
| 96 |
|
|
<td><code><a HREF="../sparc">sparc</a>/*/tst</code></td>
|
| 97 |
|
|
<td></td>
|
| 98 |
|
|
<td>SPARC test outputs</td>
|
| 99 |
|
|
</tr>
|
| 100 |
|
|
<tr>
|
| 101 |
|
|
<td><code><a HREF="../x86">x86</a>/*/tst</code></td>
|
| 102 |
|
|
<td></td>
|
| 103 |
|
|
<td>X86 test outputs</td>
|
| 104 |
|
|
</tr>
|
| 105 |
|
|
</table>
|
| 106 |
|
|
</blockquote>
|
| 107 |
|
|
|
| 108 |
|
|
<p><code>doc/install.html</code> is the HTML file for this document.</p>
|
| 109 |
|
|
|
| 110 |
|
|
<p>The installation makefile is designed so that lcc can be installed from a read-only
|
| 111 |
|
|
file system or directory, which is common in networked environments, so the distribution
|
| 112 |
|
|
can be unloaded on a central file server. <strong>You will need an existing ANSI/ISO C
|
| 113 |
|
|
compiler to build and install lcc.</strong></p>
|
| 114 |
|
|
|
| 115 |
|
|
<h2><a NAME="unix">Installation on UNIX</a></h2>
|
| 116 |
|
|
|
| 117 |
|
|
<p>The compilation components (the preprocessor, include files, and compiler proper, etc.)
|
| 118 |
|
|
are installed in a single <em>build directory</em>. On multi-platform systems supported by
|
| 119 |
|
|
a central file server, it's common to store the build directory in a location specific to
|
| 120 |
|
|
the platform and to the version of lcc, and to point a symbolic link to this location. For
|
| 121 |
|
|
example,</p>
|
| 122 |
|
|
|
| 123 |
|
|
<blockquote>
|
| 124 |
|
|
<pre>% ln -s $BUILDDIR/sparc-solaris /usr/local/lib/lcc</pre>
|
| 125 |
|
|
</blockquote>
|
| 126 |
|
|
|
| 127 |
|
|
<p>points <code>/usr/local/lib/lcc</code> to a build directory for lcc on the SPARC under Solaris. Links into <code>/usr/local/lib/lcc</code> are created for the programs <code>lcc</code>
|
| 128 |
|
|
and <code>bprint</code>. Thus, a new distribution can be installed by building it in its
|
| 129 |
|
|
own build directory and changing one symbolic link to point to that directory. If these
|
| 130 |
|
|
conventions or their equivalents are followed, the host-specific parts of the driver
|
| 131 |
|
|
program, <code>lcc</code>, can be used unmodified.</p>
|
| 132 |
|
|
|
| 133 |
|
|
<p>Installation on a UNIX system involves the following steps. Below, the build directory
|
| 134 |
|
|
is referred to as <code>BUILDDIR</code>, and the commands below are executed
|
| 135 |
|
|
from the distribution directory.<ol>
|
| 136 |
|
|
<li>Create the build directory, using a version- and platform-specific naming convention as
|
| 137 |
|
|
suggested above, and record the name of this directory in the <code>BUILDDIR</code>
|
| 138 |
|
|
environment variable:<blockquote>
|
| 139 |
|
|
<pre>% setenv BUILDDIR $BUILDDIR/sparc-solaris
|
| 140 |
|
|
% mkdir -p $BUILDDIR</pre>
|
| 141 |
|
|
</blockquote>
|
| 142 |
|
|
<p>Here and below, commands assume the C shell. Also, you'll need a version of <code>mkdir</code>
|
| 143 |
|
|
that supports the <code>-p</code> option, which creates intermediate directories as
|
| 144 |
|
|
necessary.</p>
|
| 145 |
|
|
</li>
|
| 146 |
|
|
<li>Copy the man pages to the repository for local man pages, e.g.,<blockquote>
|
| 147 |
|
|
<pre>% cp doc/*.1 /usr/local/man/man1</pre>
|
| 148 |
|
|
</blockquote>
|
| 149 |
|
|
<p>Some users copy the man pages to the build directory and create the appropriate
|
| 150 |
|
|
symbolic links, e.g., </p>
|
| 151 |
|
|
<blockquote>
|
| 152 |
|
|
<pre>% cp doc/*.1 $BUILDDIR
|
| 153 |
|
|
% ln -s $BUILDDIR/*.1 /usr/local/man/man1</pre>
|
| 154 |
|
|
</blockquote>
|
| 155 |
|
|
</li>
|
| 156 |
|
|
<li>Platform-specific include files are in directories named <code>include/</code><em>target</em><code>/</code><em>os</em>.
|
| 157 |
|
|
Create the include directory in the build directory, and copy the include hierarchy for
|
| 158 |
|
|
your platform to this directory, e.g.,<blockquote>
|
| 159 |
|
|
<pre>% mkdir $BUILDDIR/include
|
| 160 |
|
|
% cp -p -R include/sparc/solaris/* $BUILDDIR/include</pre>
|
| 161 |
|
|
</blockquote>
|
| 162 |
|
|
<p>Again, some users create a symbolic link to the appropriate directory in the
|
| 163 |
|
|
distribution instead of copying the include files. For example, at Princeton, the
|
| 164 |
|
|
distributions are stored under <code>/proj/pkg/lcc</code>, so the included files are
|
| 165 |
|
|
"installed" by creating one symbolic link: </p>
|
| 166 |
|
|
<blockquote>
|
| 167 |
|
|
<pre>% ln -s $BUILDDIR/include/sparc/solaris $BUILDDIR/include</pre>
|
| 168 |
|
|
</blockquote>
|
| 169 |
|
|
<p>If you're installing lcc on Linux, you <em>must</em> also plant a symbolic link named <code>gcc</code>
|
| 170 |
|
|
to gcc's library directory, because lcc uses gcc's C preprocessor and most of gcc's header
|
| 171 |
|
|
files:</p>
|
| 172 |
|
|
<blockquote>
|
| 173 |
|
|
<pre>% ln -s /usr/lib/gcc-lib/i386-redhat-linux/2.96 $BUILDDIR/gcc</pre>
|
| 174 |
|
|
</blockquote>
|
| 175 |
|
|
<p>The library directory shown above may be different on your Linux machine; to determine
|
| 176 |
|
|
the correct directory, browse <code>/usr/lib/gcc-lib</code>, or execute</p>
|
| 177 |
|
|
<blockquote>
|
| 178 |
|
|
<pre>% cc -v tst/8q.c</pre>
|
| 179 |
|
|
</blockquote>
|
| 180 |
|
|
<p>and examine the diagnostic output. Make sure that <code>$BUILDDIR/gcc/cpp0</code> and <code>$BUILDDIR/gcc/include</code>
|
| 181 |
|
|
are, respectively, gcc's C preprocessor and header files. On Linux, lcc looks for
|
| 182 |
|
|
include files in <code>$BUILDDIR/include</code>, <code>$BUILDDIR/gcc/include</code>, and <code>/usr/include</code>,
|
| 183 |
|
|
in that order; see <a HREF="#driver"><em>Building the Driver</em></a> and <a
|
| 184 |
|
|
href="../etc/linux.c"><code>etc/linux.c</code></a> for details.</p>
|
| 185 |
|
|
</li>
|
| 186 |
|
|
<li>The <a HREF="../makefile"><code>makefile</code></a> includes the file named by the <code>CUSTOM</code>
|
| 187 |
|
|
macro; the default is <code>custom.mk</code>, and an empty <code>custom.mk</code> is
|
| 188 |
|
|
included in the distribution. If desired, prepare a site-specification customization file
|
| 189 |
|
|
and define <code>CUSTOM</code> to the path of that file when invoking make in steps 5 and
|
| 190 |
|
|
6, e.g.,<blockquote>
|
| 191 |
|
|
<pre>make CUSTOM=<a href="http://www.cs.princeton.edu/software/lcc/pkg/solaris.mk">solaris.mk</a></pre>
|
| 192 |
|
|
</blockquote>
|
| 193 |
|
|
<p>You can, for example, use customization files to record site-specific values for macros
|
| 194 |
|
|
instead of using environment variables, and to record targets for the steps in this list.</p>
|
| 195 |
|
|
</li>
|
| 196 |
|
|
<li>Build the host-specific driver, creating a custom host-specific part, if necessary. See <a
|
| 197 |
|
|
HREF="#driver"><em>Building the Driver</em></a>.</li>
|
| 198 |
|
|
<li>Build the preprocessor, compiler proper, library, and other accessories. See <a
|
| 199 |
|
|
HREF="#rcc"><em>Building the Compiler</em></a>.</li>
|
| 200 |
|
|
<li>Plant symbolic links to the build directory and to the installed programs, e.g.,<blockquote>
|
| 201 |
|
|
<pre>% ln -s $BUILDDIR /usr/local/lib/lcc
|
| 202 |
|
|
% ln -s /usr/local/lib/{lcc,bprint} /usr/local/bin</pre>
|
| 203 |
|
|
</blockquote>
|
| 204 |
|
|
<p>Some users copy <code>bprint</code> and <code>lcc</code> into <code>/usr/local/bin</code>
|
| 205 |
|
|
instead of creating symbolic links. The advantage of creating the links for <code>lcc</code>
|
| 206 |
|
|
and <code>bprint</code> as shown is that, once established, they point indirectly to
|
| 207 |
|
|
whatever <code>/usr/local/lib/lcc</code> points to; installing a new version of lcc can be done by changing <code>/usr/local/lib/lcc</code> to point to the build
|
| 208 |
|
|
directory for the new version.</p>
|
| 209 |
|
|
</li>
|
| 210 |
|
|
</ol>
|
| 211 |
|
|
|
| 212 |
|
|
<h2><a NAME="driver">Building the Driver</a></h2>
|
| 213 |
|
|
|
| 214 |
|
|
<p>The preprocessor, compiler, assembler, and loader are invoked by a driver program, <code>lcc</code>,
|
| 215 |
|
|
which is similar to <code>cc</code> on most systems. It's described in the man page <code>doc/lcc.1</code>.
|
| 216 |
|
|
The driver is built by combining the host-independent part, <a href="../etc/lcc.c"><code>etc/lcc.c</code></a>,
|
| 217 |
|
|
with a small host-specific part. Distributed host-specific parts are named <code>etc/</code><em>os</em><code>.c</code>,
|
| 218 |
|
|
where <em>os</em> is the name of the operating system for the host on which <code>lcc</code>
|
| 219 |
|
|
is being installed. If you're following the installations conventions described above, you
|
| 220 |
|
|
can probably use one of the host-specific parts unmodified; otherwise, pick one that is
|
| 221 |
|
|
closely related to your platform, copy it to <em>whatever</em><code>.c</code>, and edit it
|
| 222 |
|
|
as described below. You should not have to edit <code>etc/lcc.c</code>.</p>
|
| 223 |
|
|
|
| 224 |
|
|
<p>We'll use <a HREF="../etc/solaris.c"><code>etc/solaris.c</code></a> as an example in
|
| 225 |
|
|
describing how the host-specific part works. This example illustrates all the important
|
| 226 |
|
|
features. Make sure you have the environment variable <code>BUILDDIR</code> set correctly,
|
| 227 |
|
|
and build the driver with a <code>make</code> command, e.g.,</p>
|
| 228 |
|
|
|
| 229 |
|
|
<blockquote>
|
| 230 |
|
|
<pre>% make HOSTFILE=etc/solaris.c lcc
|
| 231 |
|
|
cc -g -c -o $BUILDDIR/sparc-solaris/lcc.o etc/lcc.c
|
| 232 |
|
|
cc -g -c -o $BUILDDIR/sparc-solaris/host.o etc/solaris.c
|
| 233 |
|
|
cc -g -o $BUILDDIR/lcc $BUILDDIR/sparc-solaris/lcc.o $BUILDDIR/sparc-solaris/host.o</pre>
|
| 234 |
|
|
</blockquote>
|
| 235 |
|
|
|
| 236 |
|
|
<p>Of course, the actual value of <code>BUILDDIR</code> will appear in place of
|
| 237 |
|
|
<code>$BUILDDIR</code>. The symbolic name <code>HOSTFILE</code> specifies the path to the host-specific part,
|
| 238 |
|
|
either one in the distribution or <em>whatever</em><code>.c</code>. Some versions of make
|
| 239 |
|
|
may require the <code>-e</code> option in order to read the environment.</p>
|
| 240 |
|
|
|
| 241 |
|
|
<p>Here's <code>etc/solaris.c</code>:</p>
|
| 242 |
|
|
|
| 243 |
|
|
<blockquote>
|
| 244 |
|
|
<pre>/* Sparcs running Solaris 2.5.1 at CS Dept., Princeton University */
|
| 245 |
|
|
|
| 246 |
|
|
#include <string.h>
|
| 247 |
|
|
|
| 248 |
|
|
static char rcsid[] = "$ Id: solaris.c,v 1.10 1998/09/14 20:36:33 drh Exp $";
|
| 249 |
|
|
|
| 250 |
|
|
#ifndef LCCDIR
|
| 251 |
|
|
#define LCCDIR "/usr/local/lib/lcc/"
|
| 252 |
|
|
#endif
|
| 253 |
|
|
#ifndef SUNDIR
|
| 254 |
|
|
#define SUNDIR "/opt/SUNWspro/SC4.2/lib/"
|
| 255 |
|
|
#endif
|
| 256 |
|
|
|
| 257 |
|
|
char *suffixes[] = { ".c", ".i", ".s", ".o", ".out", 0 };
|
| 258 |
|
|
char inputs[256] = "";
|
| 259 |
|
|
char *cpp[] = { LCCDIR "cpp",
|
| 260 |
|
|
"-D__STDC__=1", "-Dsparc", "-D__sparc__", "-Dsun", "-D__sun__", "-Dunix",
|
| 261 |
|
|
"$1", "$2", "$3", 0 };
|
| 262 |
|
|
char *include[] = { "-I" LCCDIR "include", "-I/usr/local/include",
|
| 263 |
|
|
"-I/usr/include", 0 };
|
| 264 |
|
|
char *com[] = { LCCDIR "rcc", "-target=sparc/solaris",
|
| 265 |
|
|
"$1", "$2", "$3", 0 };
|
| 266 |
|
|
char *as[] = { "/usr/ccs/bin/as", "-Qy", "-s", "-o", "$3", "$1", "$2", 0 };
|
| 267 |
|
|
char *ld[] = { "/usr/ccs/bin/ld", "-o", "$3", "$1",
|
| 268 |
|
|
SUNDIR "crti.o", SUNDIR "crt1.o",
|
| 269 |
|
|
SUNDIR "values-xa.o", "$2", "",
|
| 270 |
|
|
"-Y", "P," SUNDIR ":/usr/ccs/lib:/usr/lib", "-Qy",
|
| 271 |
|
|
"-L" LCCDIR, "-llcc", "-lm", "-lc", SUNDIR "crtn.o", 0 };
|
| 272 |
|
|
|
| 273 |
|
|
extern char *concat(char *, char *);
|
| 274 |
|
|
|
| 275 |
|
|
int option(char *arg) {
|
| 276 |
|
|
if (strncmp(arg, "-lccdir=", 8) == 0) {
|
| 277 |
|
|
cpp[0] = concat(&arg[8], "/cpp");
|
| 278 |
|
|
include[0] = concat("-I", concat(&arg[8], "/include"));
|
| 279 |
|
|
ld[12] = concat("-L", &arg[8]);
|
| 280 |
|
|
com[0] = concat(&arg[8], "/rcc");
|
| 281 |
|
|
} else if (strcmp(arg, "-p") == 0) {
|
| 282 |
|
|
ld[5] = SUNDIR "mcrt1.o";
|
| 283 |
|
|
ld[10] = "P," SUNDIR "libp:/usr/ccs/lib/libp:/usr/lib/libp:"
|
| 284 |
|
|
SUNDIR ":/usr/ccs/lib:/usr/lib";
|
| 285 |
|
|
} else if (strcmp(arg, "-b") == 0)
|
| 286 |
|
|
;
|
| 287 |
|
|
else if (strncmp(arg, "-ld=", 4) == 0)
|
| 288 |
|
|
ld[0] = &arg[4];
|
| 289 |
|
|
else
|
| 290 |
|
|
return 0;
|
| 291 |
|
|
return 1;
|
| 292 |
|
|
}</pre>
|
| 293 |
|
|
</blockquote>
|
| 294 |
|
|
|
| 295 |
|
|
<p><code>LCCDIR</code> defaults to <code>"/usr/local/lib/lcc/"</code> unless
|
| 296 |
|
|
it's defined by a <code>-D</code> option as part of <code>CFLAGS</code> in the make
|
| 297 |
|
|
command, e.g.,</p>
|
| 298 |
|
|
|
| 299 |
|
|
<blockquote>
|
| 300 |
|
|
<pre>% make HOSTFILE=etc/solaris.c CFLAGS='-DLCCDIR=\"/v/lib/lcc/\"' lcc</pre>
|
| 301 |
|
|
</blockquote>
|
| 302 |
|
|
|
| 303 |
|
|
<p>Note the trailing slash; <code>SUNDIR</code> is provided so you can use <code>etc/solaris.c</code>
|
| 304 |
|
|
even if you have a different version of the Sun Pro compiler suite. If you're using the
|
| 305 |
|
|
gcc compiler tools instead of the Sun Pro tools, see <a HREF="../etc/gcc-solaris.c"><code>etc/gcc-solaris.c</code></a>.</p>
|
| 306 |
|
|
|
| 307 |
|
|
<p>Most of the host-specific code is platform-specific data and templates for the commands
|
| 308 |
|
|
that invoke the preprocessor, compiler, assembler, and loader. The <code>suffixes</code>
|
| 309 |
|
|
array lists the file name suffixes for C source files, preprocessed source files, assembly
|
| 310 |
|
|
language source files, object files, and executable files. <code>suffixes</code> must be
|
| 311 |
|
|
terminated with a null pointer, as shown above. The initialization of <code>suffixes</code>
|
| 312 |
|
|
in <code><a HREF="../etc/solaris.c">etc/solaris.c</a></code> are the typical ones for UNIX
|
| 313 |
|
|
systems. Each element of <code>suffixes</code> is actually a list of suffixes, separated
|
| 314 |
|
|
by semicolons; <code><a HREF="../etc/win32.c">etc/win32.c</a></code> holds an example:</p>
|
| 315 |
|
|
|
| 316 |
|
|
<blockquote>
|
| 317 |
|
|
<pre>char *suffixes[] = { ".c;.C", ".i;.I", ".asm;.ASM;.s;.S", ".obj;.OBJ", ".exe", 0 };</pre>
|
| 318 |
|
|
</blockquote>
|
| 319 |
|
|
|
| 320 |
|
|
<p>When a list is given, the first suffix is used whenever lcc needs to generate a file
|
| 321 |
|
|
name. For example, with <code><a HREF="../etc/win32.c">etc/win32.c</a></code>, lcc emits
|
| 322 |
|
|
the generated assembly code into <code>.asm</code> files.</p>
|
| 323 |
|
|
|
| 324 |
|
|
<p>The <code>inputs</code> array holds a null-terminated string of directories separated
|
| 325 |
|
|
by colons or semicolons. These are used as the default value of <code>LCCINPUTS</code>, if
|
| 326 |
|
|
the environment variable <code>LCCINPUTS</code> is not set; see the <a HREF="lcc.pdf">man
|
| 327 |
|
|
page</a>.</p>
|
| 328 |
|
|
|
| 329 |
|
|
<p>Each command template is an array of pointers to strings terminated with a null
|
| 330 |
|
|
pointer; the strings are full path names of commands, arguments, or argument placeholders,
|
| 331 |
|
|
which are described below. Commands are executed in a child process, and templates can
|
| 332 |
|
|
contain multiple commands by separating commands with newlines. The driver runs each
|
| 333 |
|
|
command in a new process.</p>
|
| 334 |
|
|
|
| 335 |
|
|
<p>The <code>cpp</code> array gives the command for running lcc's preprocessor, <code>cpp</code>.
|
| 336 |
|
|
Literal arguments specified in templates, e.g., <code>"-Dsparc"</code> in the <code>cpp</code>
|
| 337 |
|
|
command above, are passed to the command as given.</p>
|
| 338 |
|
|
|
| 339 |
|
|
<p>The strings <code>"$1"</code>, <code>"$2"</code>, and <code>"$3"</code>
|
| 340 |
|
|
in templates are placeholders for <em>lists</em> of arguments that are substituted in a
|
| 341 |
|
|
copy of the template before the command is executed. <code>$1</code> is replaced by the <em>options</em>
|
| 342 |
|
|
specified by the user; for the preprocessor, this list always contains at least <code>-D__LCC__</code>.
|
| 343 |
|
|
<code>$2</code> is replaced by the <em>input</em> files, and <code>$3</code> is replaced
|
| 344 |
|
|
by the <em>output</em> file.</p>
|
| 345 |
|
|
|
| 346 |
|
|
<p>Zero-length arguments after replacement are removed from the argument list before the
|
| 347 |
|
|
command is invoked. So, for example, if the preprocessor is invoked without an output
|
| 348 |
|
|
file, <code>"$3"</code> becomes <code>""</code>, which is removed from
|
| 349 |
|
|
the final argument list.</p>
|
| 350 |
|
|
|
| 351 |
|
|
<p>The <code>include</code> array is a list of <code>-I</code> options that specify which
|
| 352 |
|
|
directives should be searched to satisfy include directives. These directories are
|
| 353 |
|
|
searched in the order given. The first directory should be the one to which the ANSI
|
| 354 |
|
|
header files were copied as described in <a HREF="#unix">UNIX</a> or <a HREF="#win32">Windows</a>
|
| 355 |
|
|
installation instructions. The driver adds these options to <code>cpp</code>'s arguments
|
| 356 |
|
|
when it invokes the preprocessor, except when <code>-N</code> is specified.</p>
|
| 357 |
|
|
|
| 358 |
|
|
<p><code>com</code> gives the command for invoking the compiler. This template can appear
|
| 359 |
|
|
as shown above in a custom host-specific part, but the option <code>-target=sparc/solaris</code>
|
| 360 |
|
|
should be edited to the <em>target</em><code>/</code><em>os</em> for your platform. If <code>com[1]</code>
|
| 361 |
|
|
includes the string "<code>win32</code>", the driver assumes it's running on
|
| 362 |
|
|
Windows. lcc can generate code for <em>all</em> of the <em>target</em><code>/</code><em>os</em>
|
| 363 |
|
|
combinations listed in the file <code>src/bind.c</code>. The <code>-target</code> option
|
| 364 |
|
|
specifies the default combination. The driver's <code>-Wf</code> option can be used to
|
| 365 |
|
|
specify other combinations; the <a HREF="lcc.pdf">man page</a> elaborates.</p>
|
| 366 |
|
|
|
| 367 |
|
|
<p><code>as</code> gives the command for invoking the assembler. On Linux, you must be
|
| 368 |
|
|
running at least version 2.8.1 of the GNU assembler; earlier versions mis-assemble some
|
| 369 |
|
|
instructions emitted by lcc.</p>
|
| 370 |
|
|
|
| 371 |
|
|
<p><code>ld</code> gives the command for invoking the loader. For the other commands, the
|
| 372 |
|
|
list <code>$2</code> contains a single file; for <code>ld</code>, <code>$2</code> contains
|
| 373 |
|
|
all ".o" files and libraries, and <code>$3</code> is <code>a.out</code>, unless
|
| 374 |
|
|
the <code>-o</code> option is specified. As suggested in the code above, <code>ld</code>
|
| 375 |
|
|
must also specify the appropriate startup code and default libraries, including the lcc
|
| 376 |
|
|
library, <code>liblcc.a</code>.</p>
|
| 377 |
|
|
|
| 378 |
|
|
<p>The <code>option</code> function is described below; the minimal <code>option</code>
|
| 379 |
|
|
function just returns 0.</p>
|
| 380 |
|
|
|
| 381 |
|
|
<p>You can test <code>lcc</code> with the options <code>-v -v</code> to display the
|
| 382 |
|
|
commands that would be executed, e.g.,</p>
|
| 383 |
|
|
|
| 384 |
|
|
<blockquote>
|
| 385 |
|
|
<pre>% $BUILDDIR/lcc -v -v foo.c baz.c mylib.a -lX11
|
| 386 |
|
|
$BUILDDIR/sparc-solaris/lcc $ Id: lcc.c,v 4.33 2001/06/28 22:19:58 drh $
|
| 387 |
|
|
foo.c:
|
| 388 |
|
|
/usr/local/lib/lcc/cpp -D__STDC__=1 -Dsparc -D__sparc__ -Dsun -D__sun__ -Dunix -D__LCC__i
|
| 389 |
|
|
/usr/local/lib/lcc/rcc -target=sparc/solaris -v /tmp/lcc4060.i /tmp/lcc4061.s
|
| 390 |
|
|
/usr/ccs/bin/as -Qy -s -o /tmp/lcc4062.o /tmp/lcc4061.s
|
| 391 |
|
|
baz.c:
|
| 392 |
|
|
/usr/local/lib/lcc/cpp -D__STDC__=1 -Dsparc -D__sparc__ -Dsun -D__sun__ -Dunix -D__LCC__i
|
| 393 |
|
|
/usr/local/lib/lcc/rcc -target=sparc/solaris -v /tmp/lcc4060.i /tmp/lcc4061.s
|
| 394 |
|
|
/usr/ccs/bin/as -Qy -s -o /tmp/lcc4063.o /tmp/lcc4061.s
|
| 395 |
|
|
/usr/ccs/bin/ld -o a.out /opt/SUNWspro/SC4.2/lib/crti.o /opt/SUNWspro/SC4.2/lib/crt1.o /o
|
| 396 |
|
|
rm /tmp/lcc4063.o /tmp/lcc4060.i /tmp/lcc4061.s /tmp/lcc4062.o</pre>
|
| 397 |
|
|
</blockquote>
|
| 398 |
|
|
|
| 399 |
|
|
<p>As the output shows, <code>lcc</code> places temporary files in <code>/tmp</code>; if
|
| 400 |
|
|
any of the environment variables <code>TMP</code>, <code>TEMP</code>, and <code>TMPDIR</code>
|
| 401 |
|
|
are set, they override this default (in the order shown) as does the <code>-tempdir=</code><em>dir</em>
|
| 402 |
|
|
option. The default can be changed by defining <code>TEMPDIR</code> in <code>CFLAGS</code>
|
| 403 |
|
|
when building the driver.</p>
|
| 404 |
|
|
|
| 405 |
|
|
<p>The <code>option</code> function is called for the options <code>-Wo</code>, <code>-g</code>,
|
| 406 |
|
|
<code>-p</code>, <code>-pg</code>, and <code>-b</code> because these compiler options
|
| 407 |
|
|
might also affect the loader's arguments. For these options, the driver calls <code>option(arg)</code>
|
| 408 |
|
|
to give the host-specific code an opportunity to edit the <code>ld</code> command, if
|
| 409 |
|
|
necessary. <code>option</code> can change <code>ld</code>, if necessary, and return 1 to
|
| 410 |
|
|
announce its acceptance of the option. If the option is unsupported, <code>option</code>
|
| 411 |
|
|
should return 0.</p>
|
| 412 |
|
|
|
| 413 |
|
|
<p>For example, in response to <code>-g</code>, the <code>option</code> function shown
|
| 414 |
|
|
above accepts the option but does nothing else, because the <code>ld</code> and <code>as</code>
|
| 415 |
|
|
commands don't need to be modified on the SPARC. <code>-g</code> will also be added to the
|
| 416 |
|
|
compiler's options by the host-independent part of the driver. The <code>-p</code> causes <code>option</code>
|
| 417 |
|
|
to change the name of the startup code and changed the list of libraries. The <code>-b</code>
|
| 418 |
|
|
option turns on <code>lcc</code>'s per-expression profiling, the code for which is in <code>liblcc.a</code>,
|
| 419 |
|
|
so <code>option</code> need no nothing.</p>
|
| 420 |
|
|
|
| 421 |
|
|
<p>On SPARCs, the driver also recognizes <code>-Bstatic</code> and <code>-Bdynamic</code>
|
| 422 |
|
|
as linker options. The driver recognizes but ignores "<code>-target</code> <em>name</em>"
|
| 423 |
|
|
option.</p>
|
| 424 |
|
|
|
| 425 |
|
|
<p>The option <code>-Wo</code><em>arg</em> causes the driver to pass <em>arg</em> to <code>option</code>.
|
| 426 |
|
|
Such options have no other effect; this mechanism is provided to support system-specific
|
| 427 |
|
|
options that affect the commands executed by the driver. As illustrated above,
|
| 428 |
|
|
host-specific parts should support the <code>-Wo-lccdir=</code><em>dir</em> option, which
|
| 429 |
|
|
causes lcc's compilation components to be found in <em>dir</em>, because this option is
|
| 430 |
|
|
used by the test scripts, and because the driver simulates a <code>-Wo-lccdir</code>
|
| 431 |
|
|
option with the value of the environment variable <code>LCCDIR</code>, if it's defined.
|
| 432 |
|
|
The code above rebuilds the paths to the include files, preprocessor, compiler, and
|
| 433 |
|
|
library by calling <code>concat</code>, which is defined in <code>etc/lcc.c</code>.</p>
|
| 434 |
|
|
|
| 435 |
|
|
<h2><a NAME="rcc">Building the Compiler and Accessories</a></h2>
|
| 436 |
|
|
|
| 437 |
|
|
<p>To build the rest of compilation components make sure <code>BUILDDIR</code> is set
|
| 438 |
|
|
appropriately and type "<code>make all</code>". This command builds <code>librcc.a</code>
|
| 439 |
|
|
(the compiler's private library), <code>rcc</code> (the compiler proper), <code>lburg</code>
|
| 440 |
|
|
(the code-generator generator), <code>cpp</code> (the preprocessor), <code>liblcc.a</code>
|
| 441 |
|
|
(the runtime library), and <code>bprint</code> (the profile printer), all in <code>BUILDDIR</code>.
|
| 442 |
|
|
There may be warnings, but there should be no errors. If you're using an ANSI/ISO compiler
|
| 443 |
|
|
other than <code>cc</code>, specify its name with the <code>CC=</code> option, e.g.,
|
| 444 |
|
|
"<code>make CC=gcc all</code>". If you're running on a DEC ALPHA, use "<code>make
|
| 445 |
|
|
CC='cc -std1' all</code>"; the <code>-std1</code> option is essential on
|
| 446 |
|
|
the ALPHA.</p>
|
| 447 |
|
|
|
| 448 |
|
|
<p>Once <code>rcc</code> is built with the host C compiler, run the test suite to verify
|
| 449 |
|
|
that <code>rcc</code> is working correctly. If any of the steps below fail, contact us
|
| 450 |
|
|
(see <a HREF="#bugs"><em>Reporting Bugs</em></a>). The commands in the makefile run the
|
| 451 |
|
|
shell script <code>src/run.sh</code> on each C program in the test suite, <code>tst/*.c</code>.
|
| 452 |
|
|
It uses the driver, <code>$BUILDDIR/lcc</code>, so you must have the driver in the build
|
| 453 |
|
|
directory before testing <code>rcc</code>. The <em>target</em><code>/</code><em>os</em>
|
| 454 |
|
|
combination is read from the variable <code>TARGET</code>, which must be specified when
|
| 455 |
|
|
invoking <code>make</code>:</p>
|
| 456 |
|
|
|
| 457 |
|
|
<blockquote>
|
| 458 |
|
|
<pre>% make TARGET=sparc/solaris test
|
| 459 |
|
|
mkdir -p $BUILDDIR/sparc-solaris/sparc/solaris/tst
|
| 460 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/8q.s:
|
| 461 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/array.s:
|
| 462 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/cf.s:
|
| 463 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/cq.s:
|
| 464 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/cvt.s:
|
| 465 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/fields.s:
|
| 466 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/front.s:
|
| 467 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/incr.s:
|
| 468 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/init.s:
|
| 469 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/limits.s:
|
| 470 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/paranoia.s:
|
| 471 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/sort.s:
|
| 472 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/spill.s:
|
| 473 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/stdarg.s:
|
| 474 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/struct.s:
|
| 475 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/switch.s:
|
| 476 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/wf1.s:
|
| 477 |
|
|
$BUILDDIR/sparc-solaris/rcc -target=sparc/solaris $BUILDDIR/sparc-solaris/sparc/solaris/tst/yacc.s:</pre>
|
| 478 |
|
|
</blockquote>
|
| 479 |
|
|
|
| 480 |
|
|
<p>Each line in the output above is of the form</p>
|
| 481 |
|
|
|
| 482 |
|
|
<blockquote>
|
| 483 |
|
|
<p><code>$BUILDDIR/rcc -target=</code><em>target</em><code>/</code><em>os</em><code> $BUILDDIR/</code><em>target</em><code>/</code><em>os</em><code>/</code><em>X</em><code>.s:</code></p>
|
| 484 |
|
|
</blockquote>
|
| 485 |
|
|
|
| 486 |
|
|
<p>where <em>X</em> is the base name of the C program <em>X</em><code>.c</code> in the
|
| 487 |
|
|
test suite. The actual value of <code>BUILDDIR</code> will, of course, appear in
|
| 488 |
|
|
place of <code>$BUILDDIR</code>. This output identifies the compiler and the target, e.g., "<code>$BUILDDIR/rcc</code>
|
| 489 |
|
|
is generating code for a <code>sparc</code> running the <code>solaris</code> operating
|
| 490 |
|
|
system."</p>
|
| 491 |
|
|
|
| 492 |
|
|
<p>For each program in the test suite, <code>src/run.sh</code> compiles the program, drops
|
| 493 |
|
|
the generated assembly language code in <code>BUILDDIR</code>/<em>target</em><code>/</code><em>os</em>,
|
| 494 |
|
|
and uses <code>diff</code> to compare the generated assembly code with the expected code
|
| 495 |
|
|
(the code expected for <code>tst/8q.c</code> on the SPARC under Solaris is in <code>sparc/solaris/tst/8q.sbk</code>,
|
| 496 |
|
|
etc.). If there are differences, the script executes the generated code with the input
|
| 497 |
|
|
given in <code>tst</code> (the input for <code>tst/8q.c</code> is in <code>tst/8q.0</code>,
|
| 498 |
|
|
etc.) and compares the output with the expected output (the expected output from <code>tst/8q.c</code>
|
| 499 |
|
|
on the SPARC under Solaris is in <code>sparc/solaris/tst/8q.1bk</code>, etc.). The script
|
| 500 |
|
|
also compares the diagnostics from the compiler with the expected diagnostics.</p>
|
| 501 |
|
|
|
| 502 |
|
|
<p>On some systems, there may be a few differences between the generated code and the
|
| 503 |
|
|
expected code. These differences occur because the expected code is generated by cross
|
| 504 |
|
|
compilation and the least significant bits of some floating-point constants differ from
|
| 505 |
|
|
those bits in constants generated on your system. On Linux, there may be differences
|
| 506 |
|
|
because of differences in the header files between our system and yours. There should be
|
| 507 |
|
|
no differences in the output from executing the test programs.</p>
|
| 508 |
|
|
|
| 509 |
|
|
<p>Next, run the "triple test", which builds <code>rcc</code> using itself:</p>
|
| 510 |
|
|
|
| 511 |
|
|
<blockquote>
|
| 512 |
|
|
<pre>% make triple
|
| 513 |
|
|
$BUILDDIR/sparc-solaris/lcc -A -d0.6 -Wo-lccdir=$(BUILDDIR) -Isrc -I$(BUILDDIR) -o $BUILDDIR/sparc-solaris/1rcc -B$BUILDDIR/sparc-solaris/ src/alloc.c ...
|
| 514 |
|
|
src/alloc.c:
|
| 515 |
|
|
...
|
| 516 |
|
|
$BUILDDIR/sparc-solaris/lcc -A -d0.6 -Wo-lccdir=$(BUILDDIR) -Isrc -I$(BUILDDIR) -o $BUILDDIR/sparc-solaris/2rcc -B$BUILDDIR/sparc-solaris/1 src/alloc.c ...
|
| 517 |
|
|
src/alloc.c:
|
| 518 |
|
|
...
|
| 519 |
|
|
strip $BUILDDIR/sparc-solaris/[12]rcc
|
| 520 |
|
|
dd if=$BUILDDIR/sparc-solaris/1rcc of=$BUILDDIR/sparc-solaris/rcc1 bs=512 skip=1
|
| 521 |
|
|
1270+1 records in
|
| 522 |
|
|
1270+1 records out
|
| 523 |
|
|
dd if=$BUILDDIR/sparc-solaris/2rcc of=$BUILDDIR/sparc-solaris/rcc2 bs=512 skip=1
|
| 524 |
|
|
1270+1 records in
|
| 525 |
|
|
1270+1 records out
|
| 526 |
|
|
if cmp $BUILDDIR/sparc-solaris/rcc[12]; then \
|
| 527 |
|
|
mv $BUILDDIR/sparc-solaris/2rcc $BUILDDIR/sparc-solaris/rcc; \
|
| 528 |
|
|
rm -f $BUILDDIR/sparc-solaris/1rcc $BUILDDIR/sparc-solaris/rcc[12]; fi</pre>
|
| 529 |
|
|
</blockquote>
|
| 530 |
|
|
|
| 531 |
|
|
<p>This command builds <code>rcc</code> twice; once using the <code>rcc</code> built by <code>cc</code>
|
| 532 |
|
|
and again using the <code>rcc</code> built by <code>lcc</code>. The resulting binaries are
|
| 533 |
|
|
compared. They should be identical, as shown at the end of the output above. If they
|
| 534 |
|
|
aren't, our compiler is generating incorrect code; <a HREF="#bugs">contact</a> us.</p>
|
| 535 |
|
|
|
| 536 |
|
|
<p>The final version of <code>rcc</code> should also pass the test suite; that is, the
|
| 537 |
|
|
output from</p>
|
| 538 |
|
|
|
| 539 |
|
|
<blockquote>
|
| 540 |
|
|
<pre>% make TARGET=sparc/solaris test</pre>
|
| 541 |
|
|
</blockquote>
|
| 542 |
|
|
|
| 543 |
|
|
<p>should be identical to that from the previous <code>make test</code>.</p>
|
| 544 |
|
|
|
| 545 |
|
|
<p>The command "<code>make clean</code>" cleans up, but does not remove <code>rcc</code>,
|
| 546 |
|
|
etc., and "<code>make clobber</code>" cleans up and removes <code>lcc</code>, <code>rcc</code>,
|
| 547 |
|
|
and the other accessories. Test directories under <code>BUILDDIR</code> are <em>not</em>
|
| 548 |
|
|
removed; you'll need to remove these by hand, e.g.,</p>
|
| 549 |
|
|
|
| 550 |
|
|
<blockquote>
|
| 551 |
|
|
<pre>% rm -fr $BUILDDIR/sparc</pre>
|
| 552 |
|
|
</blockquote>
|
| 553 |
|
|
|
| 554 |
|
|
<p>The code generators for the other targets can be tested by specifying the desired <em>target</em><code>/</code><em>os</em>
|
| 555 |
|
|
and setting an environment variable that controls what <code>src/run.sh</code> does. For
|
| 556 |
|
|
example, to test the MIPS code generator, type</p>
|
| 557 |
|
|
|
| 558 |
|
|
<blockquote>
|
| 559 |
|
|
<pre>% setenv REMOTEHOST noexecute
|
| 560 |
|
|
% make TARGET=mips/irix test</pre>
|
| 561 |
|
|
</blockquote>
|
| 562 |
|
|
|
| 563 |
|
|
<p>As above, <code>src/run.sh</code> compares the MIPS code generated with what's
|
| 564 |
|
|
expected. There should be no differences. Setting <code>REMOTEHOST</code> to <code>noexecute</code>
|
| 565 |
|
|
suppresses the assembly and execution of the generated code. If you set <code>REMOTEHOST</code>
|
| 566 |
|
|
to the name of a MIPS machine to which you can <code>rlogin</code>, <code>src/run.sh</code>
|
| 567 |
|
|
will <code>rcp</code> the generated code to that machine and execute it there, if
|
| 568 |
|
|
necessary. See <code>src/run.sh</code> for the details.</p>
|
| 569 |
|
|
|
| 570 |
|
|
<p>You can use lcc as a cross compiler. The options <code>-S</code> and <code>-Wf-target=</code><em>target/os</em>
|
| 571 |
|
|
generate assembly code for the specified target, which is any of those listed in the file <code>src/bind.c</code>.
|
| 572 |
|
|
For example, </p>
|
| 573 |
|
|
|
| 574 |
|
|
<blockquote>
|
| 575 |
|
|
<pre>% lcc -Wf-target=mips/irix -S tst/8q.c</pre>
|
| 576 |
|
|
</blockquote>
|
| 577 |
|
|
|
| 578 |
|
|
<p>generates MIPS code for <code>tst/8q.c</code> in <code>8q.s</code>.</p>
|
| 579 |
|
|
|
| 580 |
|
|
<p>lcc can also generate code for a "symbolic" target. This target is used
|
| 581 |
|
|
routinely in front-end development, and its output is a printable representation of the
|
| 582 |
|
|
input program, e.g., the dags constructed by the front end are printed, and other
|
| 583 |
|
|
interface functions print their arguments. You can specify this target with the option <code>-Wf-target=symbolic</code>.
|
| 584 |
|
|
For example,</p>
|
| 585 |
|
|
|
| 586 |
|
|
<blockquote>
|
| 587 |
|
|
<pre>% lcc -Wf-target=symbolic -S tst/8q.c</pre>
|
| 588 |
|
|
</blockquote>
|
| 589 |
|
|
|
| 590 |
|
|
<p>generates symbolic output for <code>tst/8q.c</code> in <code>8q.s</code>. Adding <code>-Wf-html</code>
|
| 591 |
|
|
causes the symbolic target to emit HTML instead of plain text. Finally, the option <code>-Wf-target=null</code>
|
| 592 |
|
|
specifies the "null" target for which lcc emits nothing and thus only checks the
|
| 593 |
|
|
syntax and semantics of its input files.</p>
|
| 594 |
|
|
|
| 595 |
|
|
<h2><a NAME="win32">Installation on Windows</a></h2>
|
| 596 |
|
|
|
| 597 |
|
|
<p>On Windows, lcc is designed to work with Microsoft's Visual
|
| 598 |
|
|
C++ (VC), version 5.0 and above, and Microsoft's Assembler, MASM. It uses the VC header files,
|
| 599 |
|
|
libraries, and command-line tools, and it uses MASM to assemble the code it generates.
|
| 600 |
|
|
You must use MASM 6.11d or later,
|
| 601 |
|
|
because earlier releases generate incorrect COFF object files. MASM
|
| 602 |
|
|
6.15 is available as part of the free
|
| 603 |
|
|
<a href="http://msdn.microsoft.com/vstudio/downloads/ppack/default.asp">Visual
|
| 604 |
|
|
C++ 6.0 Processor Pack</a>.</p>
|
| 605 |
|
|
|
| 606 |
|
|
<p>Building the distribution components from the ground up requires Microsoft's Visual
|
| 607 |
|
|
C/C++ compiler, Microsoft's make, <code>nmake</code>, and the standard Windows command
|
| 608 |
|
|
interpreter. <a HREF="../makefile.nt"><code>makefile.nt</code></a> is written to use only <code>nmake</code>.
|
| 609 |
|
|
As on UNIX systems, the compilation components are installed in a single <em>build
|
| 610 |
|
|
directory</em>, and the top-level programs, <code>lcc.exe</code> and <code>bprint.exe</code>,
|
| 611 |
|
|
are installed in a directory on the PATH. If the conventions used below are followed, the
|
| 612 |
|
|
Windows-specific parts of the driver program, <code>lcc.exe</code>, can be used
|
| 613 |
|
|
unmodified.</p>
|
| 614 |
|
|
|
| 615 |
|
|
<p>Building from the source distribution on a Windows system involves the following steps.
|
| 616 |
|
|
Below, the build directory is referred to as <code>BUILDDIR</code>, and the distribution
|
| 617 |
|
|
is in <code>\dist\lcc</code>.
|
| 618 |
|
|
|
| 619 |
|
|
<ol>
|
| 620 |
|
|
<li>Create the build directory, perhaps using a version- and platform-specific naming
|
| 621 |
|
|
convention as suggested in <a HREF="#unix"><em>Installation on UNIX</em></a>, and record
|
| 622 |
|
|
the name of this directory in the <code>BUILDDIR</code> environment variable:<blockquote>
|
| 623 |
|
|
<pre>C:\dist\lcc>set BUILDDIR=\progra~1\lcc\<i>version</i>\bin
|
| 624 |
|
|
C:\dist\lcc>mkdir %BUILDDIR%</pre>
|
| 625 |
|
|
</blockquote>
|
| 626 |
|
|
<p>The default build, or installation, directory is <code>\Program Files\lcc\</code><i>version</i><code>\bin</code>,
|
| 627 |
|
|
where <i>version</i> is the version number, e.g., 4.2, but the <code>nmake</code> commands require that you use the corresponding 8.3 file name, <code>progra~1</code>,
|
| 628 |
|
|
instead of <code>Program Files</code>.</p>
|
| 629 |
|
|
</li>
|
| 630 |
|
|
<li><a HREF="../etc/win32.c"><code>etc\win32.c</code></a> is the Windows-specific part of
|
| 631 |
|
|
the driver. It assumes that environment variable <code>include</code> gives the locations
|
| 632 |
|
|
of the VC header files and that the linker (<code>link.exe</code>) and the assembler (<code>ml.exe</code>)
|
| 633 |
|
|
are on the PATH. It also assumes that the macro <code>LCCDIR</code> gives the build
|
| 634 |
|
|
directory. If necessary, revise a copy of <a HREF="../etc/win32.c"><code>etc\win32.c</code></a>
|
| 635 |
|
|
to reflect the conventions on your computer (see <a HREF="#driver"><em>Building the Driver</em></a>),
|
| 636 |
|
|
then build the driver, specifying the default temporary directory, if necessary:<blockquote>
|
| 637 |
|
|
<pre>C:\dist\lcc>nmake -f makefile.nt HOSTFILE=etc/win32.c lcc
|
| 638 |
|
|
...
|
| 639 |
|
|
cl -nologo -Zi -MLd -Fd%BUILDDIR%\ -c -Fo%BUILDDIR%\lcc.obj etc/lcc.c
|
| 640 |
|
|
lcc.c
|
| 641 |
|
|
cl -nologo -Zi -MLd -Fd%BUILDDIR%\ -c -Fo%BUILDDIR%\host.obj etc/win32.c
|
| 642 |
|
|
win32.c
|
| 643 |
|
|
cl -nologo -Zi -MLd -Fd%BUILDDIR%\ -Fe%BUILDDIR%\lcc.exe %BUILDDIR%\lcc.obj %BUILDDIR%\host.obj</pre>
|
| 644 |
|
|
</blockquote>
|
| 645 |
|
|
<p>If you make a copy of <code>etc\win32.c</code>, specify the path of the copy as the
|
| 646 |
|
|
value of <code>HOSTFILE</code>. For example, if you copy <code>etc\win32.c</code> to <code>BUILDDIR</code>
|
| 647 |
|
|
and edit it, use the command</p>
|
| 648 |
|
|
<blockquote>
|
| 649 |
|
|
<pre>C:\dist\lcc>nmake -f makefile.nt HOSTFILE=%BUILDDIR%\win32.c lcc</pre>
|
| 650 |
|
|
</blockquote>
|
| 651 |
|
|
</li>
|
| 652 |
|
|
<li>Build the preprocessor, compiler proper, library, and other accessories (see <a
|
| 653 |
|
|
HREF="#rcc"><em>Building the Compiler</em></a>):<blockquote>
|
| 654 |
|
|
<pre>C:\dist\lcc>nmake -f makefile.nt all</pre>
|
| 655 |
|
|
</blockquote>
|
| 656 |
|
|
<p>This command uses the VC command-line tools <code>cl</code> and <code>lib</code> to
|
| 657 |
|
|
build <code>bprint.exe</code>, <code>cpp.exe</code>, <code>lburg.exe</code>, <code>liblcc.lib</code>,
|
| 658 |
|
|
<code>librcc.lib</code>, and <code>rcc.exe</code>, all in <code>BUILDDIR</code>. There may
|
| 659 |
|
|
be some warnings, but there should be no warnings.</p>
|
| 660 |
|
|
</li>
|
| 661 |
|
|
<li>Create a test directory and run the test suite:<blockquote>
|
| 662 |
|
|
<pre>C:\dist\lcc>mkdir %BUILDDIR%\x86\win32\tst
|
| 663 |
|
|
C:\dist\lcc>nmake -f makefile.nt test</pre>
|
| 664 |
|
|
</blockquote>
|
| 665 |
|
|
<p>This command compiles each program in <a HREF="../tst">tst</a>, compares the generated
|
| 666 |
|
|
assembly code and diagnostics with the expected assembly code and diagnostics, executes
|
| 667 |
|
|
the program, and compares the output with the expected output (using <code>fc</code>). For
|
| 668 |
|
|
example, when the nmake command compiles <a HREF="../tst/8q.c"><code>tst\8q.c</code></a>,
|
| 669 |
|
|
it leaves the generated assembly code and diagnostic output in <code>%BUILDDIR%\x86\win32\tst\8q.s</code>
|
| 670 |
|
|
and <code>%BUILDDIR%\x86\win32\tst\8q.2</code>, and it compares them with the expected
|
| 671 |
|
|
results in <code>x86\win32\tst\8q.sbk</code>. It builds the executable program in <code>%BUILDDIR%\x86\win32\tst\8q.exe</code>,
|
| 672 |
|
|
runs it, and redirects the output to <code>%BUILDDIR%\x86\win32\tst\8q.1</code>, which it
|
| 673 |
|
|
compares with <code>x86\win32\tst\8q.1bk</code>. The output from this step is voluminous,
|
| 674 |
|
|
but there should be no differences and no errors.</p>
|
| 675 |
|
|
</li>
|
| 676 |
|
|
<li>Run the "triple" test, which compiles <code>rcc</code> with itself and
|
| 677 |
|
|
verifies the results:<blockquote>
|
| 678 |
|
|
<pre>C:\dist\lcc>nmake -f makefile.nt triple
|
| 679 |
|
|
...
|
| 680 |
|
|
Assembling: C:/TEMP/lcc2001.asm
|
| 681 |
|
|
fc /b %BUILDDIR%\1rcc.exe %BUILDDIR%\2rcc.exe
|
| 682 |
|
|
Comparing files %BUILDDIR%\1rcc.exe and %BUILDDIR%\2RCC.EXE
|
| 683 |
|
|
00000088: B4 D5</pre>
|
| 684 |
|
|
</blockquote>
|
| 685 |
|
|
<p>This command builds <code>rcc</code> twice; once using the <code>rcc</code> built by VC
|
| 686 |
|
|
and again using the <code>rcc</code> built by <code>lcc</code>. The resulting binaries are
|
| 687 |
|
|
compared using <code>fc</code>. They should be identical, except for one or two bytes of
|
| 688 |
|
|
timestamp data, as shown at the end of the output above (which will be
|
| 689 |
|
|
different on your system). If <code>1rcc.exe</code> and <code>2rcc.exe</code> aren't
|
| 690 |
|
|
identical, our compiler is
|
| 691 |
|
|
generating incorrect code; <a HREF="#bugs">contact</a> us.</p>
|
| 692 |
|
|
</li>
|
| 693 |
|
|
<li>Copy <code>lcc.exe</code> and <code>bprint.exe</code> to a directory on your PATH, e.g.,<blockquote>
|
| 694 |
|
|
<pre>C:\dist\lcc>copy %BUILDDIR%\lcc.exe \bin
|
| 695 |
|
|
1 file(s) copied.
|
| 696 |
|
|
|
| 697 |
|
|
C:\dist\lcc>copy %BUILDDIR%\bprint.exe \bin
|
| 698 |
|
|
1 file(s) copied.</pre>
|
| 699 |
|
|
</blockquote>
|
| 700 |
|
|
</li>
|
| 701 |
|
|
<li>Finally, clean up:<blockquote>
|
| 702 |
|
|
<pre>C:\dist\lcc>nmake -f makefile.nt clean</pre>
|
| 703 |
|
|
</blockquote>
|
| 704 |
|
|
<p>This command removes the derived files in <code>BUILDDIR</code>, but does not remove <code>rcc.exe</code>,
|
| 705 |
|
|
etc.; "<code>nmake -f makefile.nt clobber</code>" cleans up and removes all
|
| 706 |
|
|
executables and libraries. Test directories under <code>BUILDDIR</code> are <em>not</em>
|
| 707 |
|
|
removed; you'll need to remove these by hand, e.g.,</p>
|
| 708 |
|
|
<blockquote>
|
| 709 |
|
|
<pre>C:\dist\lcc>rmdir %BUILDDIR%\x86 /s
|
| 710 |
|
|
%BUILDDIR%\x86, Are you sure (Y/N)? y</pre>
|
| 711 |
|
|
</blockquote>
|
| 712 |
|
|
</li>
|
| 713 |
|
|
</ol>
|
| 714 |
|
|
|
| 715 |
|
|
<h2><a NAME="bugs">Reporting Bugs</a></h2>
|
| 716 |
|
|
|
| 717 |
|
|
<p>lcc is a large, complex program. We find and repair errors routinely. If you think that
|
| 718 |
|
|
you've found a error, follow the steps below, which are adapted from the instructions in
|
| 719 |
|
|
Chapter 1 of <cite>A Retargetable C Compiler: Design and Implementation</cite>.
|
| 720 |
|
|
|
| 721 |
|
|
<ol>
|
| 722 |
|
|
<li>If you don't have a source file that displays the error, create one. Most errors are
|
| 723 |
|
|
exposed when programmers try to compile a program they think is valid, so you probably
|
| 724 |
|
|
have a demonstration program already.</li>
|
| 725 |
|
|
<li>Preprocess the source file and capture the preprocessor output. Discard the original
|
| 726 |
|
|
code.</li>
|
| 727 |
|
|
<li>Prune your source code until it can be pruned no more without sending the error into
|
| 728 |
|
|
hiding. We prune most error demonstrations to fewer than five lines.</li>
|
| 729 |
|
|
<li>Confirm that the source file displays the error with the <em>distributed</em> version of
|
| 730 |
|
|
lcc. If you've changed lcc and the error appears only in your version, then you'll have to
|
| 731 |
|
|
chase the error yourself, even if it turns out to be our fault, because we can't work on
|
| 732 |
|
|
your code.</li>
|
| 733 |
|
|
<li>Annotate your code with comments that explain why you think that lcc is
|
| 734 |
|
|
wrong. If lcc dies with an assertion failure, please tell us where it died. If
|
| 735 |
|
|
lcc crashes, please report the last part of the call chain if you can. If lcc
|
| 736 |
|
|
is rejecting a program you think is valid, please tell us why you think it's
|
| 737 |
|
|
valid, and include supporting page numbers in the ANSI Standard or the
|
| 738 |
|
|
appropriate section in <cite>C: A Reference Manual</cite>, 4th edition by S. B. Harbison
|
| 739 |
|
|
and G. L. Steele, Jr. (Prentice Hall, 1995). If lcc silently generates incorrect code for
|
| 740 |
|
|
some construct, please include the corrupt assembly code in the comments and flag the
|
| 741 |
|
|
incorrect instructions if you can.</li>
|
| 742 |
|
|
<li>Confirm that your error hasn't been fixed already. The latest version of lcc is always
|
| 743 |
|
|
available for anonymous <code>ftp</code> from <code>ftp.cs.princeton.edu</code> in <a
|
| 744 |
|
|
HREF="ftp://ftp.cs.princeton.edu/pub/lcc"><code>pub/lcc</code></a>. A <a
|
| 745 |
|
|
HREF="ftp://ftp.cs.princeton.edu/pub/lcc/README"><code>README</code></a> file there gives
|
| 746 |
|
|
acquisition details, and the <a HREF="../LOG"><code>LOG</code></a> file reports what errors
|
| 747 |
|
|
were fixed and when they were fixed. If you report a error that's been fixed, you might
|
| 748 |
|
|
get a canned reply.</li>
|
| 749 |
|
|
<li>Post your program to the newsgroup <a href="news:comp.compilers.lcc"><code>comp.compilers.lcc</code></a>
|
| 750 |
|
|
using a USENET newsreader like those at <a href="http://www.dejanews.com/">http://www.dejanews.com/</a>
|
| 751 |
|
|
and <a href="http://groups.google.com/">http://groups.google.com/</a>.
|
| 752 |
|
|
Please post only valid C programs; put all remarks in C comments so that we can process
|
| 753 |
|
|
reports semi automatically.</li>
|
| 754 |
|
|
</ol>
|
| 755 |
|
|
|
| 756 |
|
|
<h2><a NAME="mailinglist">Keeping in Touch</a></h2>
|
| 757 |
|
|
|
| 758 |
|
|
<p>The USENET newsgroup <a href="news:comp.compilers.lcc">comp.compilers.lcc</a> is an
|
| 759 |
|
|
unmoderated newsgroup that serves as a forum for all topics related to the installation,
|
| 760 |
|
|
use, and development of lcc. You can post messages to comp.compilers.lcc using any USENET
|
| 761 |
|
|
newsreader or by visiting <a href="http://www.dejanews.com/">http://www.dejanews.com/</a>,
|
| 762 |
|
|
which also includes an archive of recent postings.</p>
|
| 763 |
|
|
|
| 764 |
|
|
<hr>
|
| 765 |
|
|
|
| 766 |
|
|
<address>
|
| 767 |
|
|
<a HREF="http://www.research.microsoft.com/~cwfraser/">Chris Fraser</a> / <a
|
| 768 |
|
|
HREF="mailto:cwfraser@microsoft.com">cwfraser@microsoft.com</a><br>
|
| 769 |
|
|
<a HREF="http://www.research.microsoft.com/~drh/">David Hanson</a> / <a
|
| 770 |
|
|
HREF="mailto:drh@microsoft.com">drh@microsoft.com</a><br>
|
| 771 |
|
|
$Revision: 1.45 $ $Date: 2002/09/04 18:33:24 $
|
| 772 |
|
|
</address>
|
| 773 |
|
|
</body>
|
| 774 |
|
|
</html>
|
