NetBSD's link editor needs symbols for which a 32-bit relocation
is calculated to actually be on a divisible-by-4 address. .bss
segment symbols are on a divisible-by-8 address.

Output of name of each symbol is preceeded by an .align 4
or .align 8 assembler directive.

Outputs "stabs" debugger symbols for NetBSD's gdb. The original code generator output
stabs for Sun's old a.out dbx debugger. Apparently, there are differences.

stabs debugger symbols with n_type fields of N_FUN, N_LSYM, N_PSYM are at the end
of the code for the function they're associated with, not at or
near the beginning.

The compiler driver (the "lcc" program itself),
runs the assembly-language compiler
output through a perl script. Apparently, the SunOS assembler implements
two pseudo-opcodes that NetBSD's doesn't. The opcodes are st2
and ld2.
I could not figure out how to get the lcc compiler to emit pairs of
st and ld instructions. It's just not in the lcc-3.6 code-generator-
generator's power to consider pairs of 32-bit floating point registers
as a single 64-bit fp register. For starters, the code generator never
deals with register numbers, only with structs that represent registers.
There's virtually no way to get the number of the first of the pair of
registers at code generation time.

NetBSD include files are mostly ANSI C compliant to begin with. The
original distribution has include files intended for SunOS, which isn't
ANSI C compliant at all. NetBSD uses one of the lcc distribution include
files, stdarg.h, since the NetBSD stdarg.h is very dependent on the gcc
implementation.

I've compiled a bunch of my own C programs, including some with
flex, yacc and
spin
output, and even the
twm window manager from the X11R6,
patchlevel 12 tree. Of course, lcc itself is re-compiled with lcc.

There are limitations in this port. lcc-3.6 is pretty much stuck
on the idea of 32-bit int and long types. 64-bit types, such as
"long long" are pretty close to impossible to add to it. The
limitation here is that since NetBSD file offsets are 64-bit, system
call level file and filesystem manipulation is not possible with
this port.

It also requires perl: the compiler driver works over the
assembly-language compiler output with a perl script.