| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
and add support to allow users to set their CPUTYPE in make.conf.
|
| |
|
|
|
|
|
|
| |
I overlooked this because a SSP kernel booted for me.
Apologises to: ticso
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- It is opt-out for now so as to give it maximum testing, but it may be
turned opt-in for stable branches depending on the consensus. You
can turn it off with WITHOUT_SSP.
- WITHOUT_SSP was previously used to disable the build of GNU libssp.
It is harmless to steal the knob as SSP symbols have been provided
by libc for a long time, GNU libssp should not have been much used.
- SSP is disabled in a few corners such as system bootstrap programs
(sys/boot), process bootstrap code (rtld, csu) and SSP symbols themselves.
- It should be safe to use -fstack-protector-all to build world, however
libc will be automatically downgraded to -fstack-protector because it
breaks rtld otherwise.
- This option is unavailable on ia64.
Enable GCC stack protection (aka Propolice) for kernel:
- It is opt-out for now so as to give it maximum testing.
- Do not compile your kernel with -fstack-protector-all, it won't work.
Submitted by: Jeremie Le Hen <jeremie@le-hen.org>
|
|
|
|
|
| |
PR: 123518
Submitted by: Marc Olzheim <marcolz@stack.nl>
|
|
|
|
| |
Approved by: cognet (mentor)
|
|
|
|
|
|
|
| |
compiler invocation. This is just to help get over the hump of people
tracking down bugs that may cross the GCC 4.2 upgrade.
It is envisioned that this option goes away after a suitable amount
of time.
|
|
|
|
|
|
| |
Switch ia64 kernels to -fpic. This is likely wrong, but at least gets
ia64 kernels to compile and link with GCC 4.2. The previous -mno-sdata
trick is not working anymore.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
t1# uname -m
sparc64
t1# sysctl hw.physmem
hw.physmem: 17150509056
t1# kldload reiserfs
t1# kldstat
Id Refs Address Size Name
1 3 0xc0000000 58cc38 kernel
2 1 0xcbe70000 234000 xfs.ko
3 1 0xcc0b6000 110000 reiserfs.ko
|
| |
|
|
|
|
|
|
|
| |
`-Wundef'
Warn whenever an identifier which is not a macro is encountered in
an `#if' directive, outside of `defined'. Such identifiers are
replaced with zero.
|
| |
|
| |
|
|
|
|
| |
are there and that it does not have an effect on user applications.
|
| |
|
|
|
|
|
|
| |
I think all we really need is -fno-sse2.
I really don't like cluttering up the compiler invocation,
but this bigger hammer will fix reported problems for now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
to simplify the curthread expansion some months ago.
|
|
|
|
| |
Submitted by: gallatin
|
|
|
|
|
|
|
| |
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)
|
| |
|
| |
|
|
|
|
| |
Reminded by: bde
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
the gcc lossage that caused it to be turned off was fixed.
Tested with: i386/{GENERIC,LINT,...}, alpha/GENERIC
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
in a kernel config file. This should minimize the tearing-out-hair process
while updating the kernel for gcc-3 compliance.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
I should have done it that way in the first place.
Pointed-out-by: bde
|
|
|
|
| |
Submitted by: Allen Campbell <allenc@verinet.com>
|
|
|
|
| |
This reduces the size of the kernel and modules when compiled with GCC 2.95.
|
| |
|
|
|
|
|
|
| |
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".
|
| |
|
| |
|
|
|
|
|
|
| |
kernel modules are built with the right flags.
Suggested by: Andrew Gallatin <gallatin@cs.duke.edu>
|
|
|
|
| |
Reviewed by: cvs-committers@freebsd.org
|
|
|
|
|
| |
-current version of gcc. Without it, -Wformat would complain about all
the nonstandard %[Dbrz] formats in the kernel.
|
| |
|