svn commit: r326758 - in head/sys/i386: conf include

[Bruce Evans]

On Wed, 20 Dec 2017, John Baldwin wrote:

> On Wednesday, December 20, 2017 10:16:58 AM Nathan Whitehorn wrote:
>> ...
>> With GCC 4, it takes a little while, but trying to build ports over NFS
>> is a sure-fire way to bring down the kernel. I haven't tried any other
>> compilers.
>
> Ah, I have only done things like run binaries over NFS and compile simple
> test programs over NFS with GCC 4 (I do run a gdb binary over NFS against
> itself which probably involves a bit of I/O due to debug symbols, etc. but
> still not as onerous as building lots of ports.  I cross-build the GDB on
> the host due to qemu being too slow).

I use gcc-4.2.1 on i386 and amd64 with no problems except source code
breakage.   I use nfs a lot, but not zfs or newer networking.

> clang insta-panics for even trivial
> things like 'ls' and tab-completion though.  It's definitely much worse
> than either version of GCC.

It is is indeed worse in every way :-) except it can build kernels
that run a couple of percent faster, so I don't use it.  It doesn't
support standard flags like -fno-inline-functions-called-once.  I use
anti-inlining flags like this mainly to simplify debugging, but they
help reduce stack bloat.  Kernels build with excessive inlining still
don't crash here.

The mechanism for stack bloat by inlining might be that when inlining
a bunch of functions, say all leaf functions, the stacks for all the
functions get added to the callee and don't get combined.

I wonder if -fstack-protector is any use.  I tried using the correct value
for KSTACK_PAGES (1) on i386, but there was always too much bloat for
that so it crashed fast.  -fstack-protector didn't help, and it crashed
with a double fault so there was no usable stack trace.  Automatically
expanding the stack by 1 page in the double fault handler would be not
much harder than finding the old stack to trace it.

Bruce