From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 2 15:48:51 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5F38640 for ; Thu, 2 Oct 2014 15:48:51 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B5E7E681 for ; Thu, 2 Oct 2014 15:48:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s92Fmp8k068946 for ; Thu, 2 Oct 2014 15:48:51 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s92FmpVo068945 for freebsd-hackers@freebsd.org; Thu, 2 Oct 2014 15:48:51 GMT (envelope-from bdrewery) Received: (qmail 5099 invoked from network); 2 Oct 2014 10:48:46 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 2 Oct 2014 10:48:46 -0500 Message-ID: <542D73D3.9040109@FreeBSD.org> Date: Thu, 02 Oct 2014 10:48:35 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Kernel/Compiler bug References: <20141001031553.GA14360@gta.com> <20141001134044.GA57022@gta.com> <542C8C75.30007@FreeBSD.org> <20141002075537.GU26076@kib.kiev.ua> <20141002140232.GA52387@gta.com> In-Reply-To: <20141002140232.GA52387@gta.com> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DlOo11nMxAEEGbmuWhmuxvn8p6c5Ufx60" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:48:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DlOo11nMxAEEGbmuWhmuxvn8p6c5Ufx60 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/2/2014 9:02 AM, Larry Baird wrote: >>> 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=20 >> 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. >=20 > Overall I aggree with your comments. The fact is that I have been usi= ng > -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 fo= r > 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. Sin= ce > people have been runing 10.0 for a while without issue, maybe me concer= n > 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. >=20 > Larry >=20 I think at the very least we should have a DISABLE_OPTIMIZATION option that sets -O0 and increases stack size. I built a kernel with -O0 some months ago and hit a panic on boot and did not look into why. It makes sense now though. It would have been nice if it were more obviously documented or automatically handled. --=20 Regards, Bryan Drewery --DlOo11nMxAEEGbmuWhmuxvn8p6c5Ufx60 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJULXPXAAoJEDXXcbtuRpfPMOwH/1zk51rg4TtQO3hfH0fQiAp6 eb9JC98X/PFukhkUd3byag2juvuP4hZ1loy6VFn8vE5t0+CriH1QhZk8R67bxDpC uY23gko7PnH+1YL6nsbw7PFJjqQIirtMklTnxecSgiURfKD8btoY+dH4EDjgjJsq 6ButnRgPo8Lz0K5H5JHyatBdUg3dhHk8O0k98HYgVtmcIGhioewW82XsB+2iWdNi mKOBvtD1NSObRByn/4GLNP6VSOPKU6Zh+BdfRofuMTynSQwdRpT+PjwgznQyLNRE cYz9UOCPvHQPa08kVlq6ssJSIH19vKOHIVbW4b/dZlF8kiQLlFr6VbILejYpaF0= =wNoz -----END PGP SIGNATURE----- --DlOo11nMxAEEGbmuWhmuxvn8p6c5Ufx60--