Kernel/Compiler bug

[Larry Baird]

> > Is this something that can be bumped in the tree for GENERIC?
> 
> The cost of the increased size for kernel stack is significant, even
> on architectures with ample KVA.  This must not be done just because 
> some non-default kernel settings cause stack overflow.  If somebody
> feels himself qualified enough to tune compiler options, it must
> understand the consequences and do other required adjustments,
> including kernel stack size tuning.
> 
> FWIW, there was old reason why -O0 did not worked for the kernel.
> The cpufunc.h inlines are not provided in non-inline version, and
> at least gcc at -O0 level sometimes generated the call to nonexisting
> function, leading to linking failure.  It is curious that clang always
> inlines at -O0, but it is possible, although unlikely, that kernel
> source was changed to be immune.

Overall I aggree with  your comments.  The fact is that I have been using
-O0 and -O1 on custom kernels for years. It makes using kgdb much more
effective.  Both optimization levels work for a custom kernel I have for
FreeBSD 10.0 but do not work for FreeBSD 10.1. I just tried turning off
optimization for a FreeBSD 10.0 release GENERIC kernel. Same issue.  My
concern is that opimized kernels may be close to the edge as well.  Since
people have been runing 10.0 for a while without issue, maybe me concern
is unfounded.  Anybody have any thoughts on how to instrument a kernel
build option to check for maximum used stack depth? It would be nice to
prove that my concern is unfounded.

Larry

-- 
------------------------------------------------------------------------
Larry Baird
Global Technology Associates, Inc. 1992-2012 	| http://www.gta.com
Celebrating Twenty Years of Software Innovation | Orlando, FL
Email: lab at gta.com                 		| TEL 407-380-0220