Intel C/C++ compiler (lang/icc) to build the kernel.
The icc CPUTYPE CFLAGS use icc v7 syntax, icc v8 moans about them, but
doesn't abort. They also produce CPU specific code (new instructions
of the CPU, not only CPU specific scheduling), so if you get coredumps
with signal 4 (SIGILL, illegal instruction) you've used the wrong
CPUTYPE.
Incarnations of this patch survive gcc compiles and my make universe.
I use it on my desktop.
To use it update share/mk, add
/usr/local/intel/compiler70/ia32/bin (icc v7, works)
or
/usr/local/intel_cc_80/bin (icc v8, doesn't work)
to your PATH, make sure you have a new kernel compile directory
(e.g. MYKERNEL_icc) and run
CFLAGS="-O2 -ip" CC=icc make depend
CFLAGS="-O2 -ip" CC=icc make
in it.
Don't compile with -ipo, the build infrastructure uses ld directly to
link the kernel and the modules, but -ipo needs the link step to be
performed with Intel's linker.
Problems with icc v8:
- panic: npx0 cannot be emulated on an SMP system
- UP: first start of /bin/sh results in a FP exception
Parts of this commit contains suggestions or submissions from
Marius Strobl <marius@alchemy.franken.de>.
Reviewed by: silence on -arch
Submitted by: netchild
the amd64 implementation of the pcpu macros is even more verbose than on
i386 and that causes gcc to way overestimate the complexity of this
2-instruction macro. The other platforms can probably lower their
default values.
section to stop gcc generating the dwarf2 .eh_frame unwind tables. It
is dead weight for the time being. Maybe it can be used to perform
stack traces and/or get the location of function arguments in ddb, but
that requires a dwarf2 runtime interpreter, which we do not have.
Approved by: re (amd64 "safe" bits)
systems. Of note:
- Implement a direct mapped region using 2MB pages. This eliminates the
need for temporary mappings when getting ptes. This supports up to
512GB of physical memory for now. This should be enough for a while.
- Implement a 4-tier page table system. Most of the infrastructure is
there for 128TB of userland virtual address space, but only 512GB is
presently enabled due to a mystery bug somewhere. The design of this
was heavily inspired by the alpha pmap.c.
- The kernel is moved into the negative address space(!).
- The kernel has 2GB of KVM available.
- Provide a uma memory allocator to use the direct map region to take
advantage of the 2MB TLBs.
- Fixed some assumptions in the bus_space macros about the ability
to fit virtual addresses in an 'int'.
Notable missing things:
- pmap_growkernel() should be able to grow to 512GB of KVM by expanding
downwards below kernbase. The kernel must be at the top 2GB of the
negative address space because of gcc code generation strategies.
- need to fix the >512GB user vm code.
Approved by: re (blanket)
Fix the "@gprel relocation against dynamic symbol xxx" linker error.
Variables defined in the link unit and small enough to be put in the
short data section will have a gp-relative access sequence (using the
@gprel relocation). It is invalid to have @gprel relocations in shared
libraries, because they are to be resolved by the static linker and
not the dynamic linker. The -fpic option will cause @ltoff relocations
for @gprel relocations, but the side-effects are untested (if any).
Instead, disable/eliminate the short data section to achieve the same.
This reduces the size of GENERIC's text space by 73999 bytes (about 2%).
The bloat is from approximately 3437 strings longer than 31 characters
being padded to a 32-byte boundary.
ev6 or pca56 etc this downgrades the cpu specification passed to gas.
As a result, gas will fail when gcc generates media instructions (in
uipc_usrreq.c). This only affects what gas will accept, not what gcc
generates or what our *.s file contain.
back to -fformat-extensions (or whatever) when we have the functionality.
We are gaining warnings again that should be fixed but the are being hidden
by NO_WERROR and all the -Wformat noise.
is not implied by -Wall as claimed by gcc.1. Adding it causes a
measly 7193 new warnings for LINT, mostly for "unused parameter" and
"comparison between signed and unsigned".
variables were lost when we removed -W, and 23 new ones including at
least one serious one have crept in for LINT.
Restored -Winline to CFLAGS. This gives only 3 old warnings and 1 new
for LINT.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
2.2 are more obvious. -Winline is unimportant, but -W gives thousands
of warnings for comparisions. Turning off -W also loses warnings for:
- auto variables clobbered by longjmp. Not much of a problem in the kernel.
- functions returning without a value. I don't like losing this.
- an expression statement or the left side of a comma operand contains no
side effects. Turning this off also stops warnings for the low quality
debugging macros in gsc.c and lpt.c.
Should be in 2.2.
Also disabled -Wunused. It caused too many warnings even for me.
The sign mismatch warnings should be fixed first. They are more
important and harder to disable (they are controlled by -W, which
controls too many things).
