Date: Thu, 02 Oct 2014 10:48:35 -0500 From: Bryan Drewery <bdrewery@FreeBSD.org> To: freebsd-hackers@freebsd.org Subject: Re: Kernel/Compiler bug Message-ID: <542D73D3.9040109@FreeBSD.org> In-Reply-To: <20141002140232.GA52387@gta.com> References: <20141001031553.GA14360@gta.com> <CAFMmRNxAYcr8eEY0SJsX3zkRadjT29-mfsGcSTmG_Yx-Hidi6w@mail.gmail.com> <20141001134044.GA57022@gta.com> <FBB9E4C3-55B9-4917-9953-F8BC9AE43619@FreeBSD.org> <542C8C75.30007@FreeBSD.org> <20141002075537.GU26076@kib.kiev.ua> <20141002140232.GA52387@gta.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?542D73D3.9040109>