Date: Sun, 4 Aug 2013 22:28:23 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: amd64: -O2 even with DEBUG Message-ID: <20130804202823.GB39246@stack.nl> In-Reply-To: <51F37578.2080405@FreeBSD.org> References: <51F221D4.8040308@FreeBSD.org> <20130726185425.GS26412@funkthat.com> <51F37578.2080405@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jul 27, 2013 at 10:23:36AM +0300, Andriy Gapon wrote: > on 26/07/2013 21:54 John-Mark Gurney said the following: > > Andriy Gapon wrote this message on Fri, Jul 26, 2013 at 10:14 +0300: > >> I wonder why amd64 is distinguished to have -O2 in COPTFLAGS even > >> when DEBUG is defined. For all other archs it's -O for that case. > >> Perhaps, this was discussed / explained in the past, but I would > >> appreciate it being said again (or even written as a comment in > >> kern.pre.mk). > > It's probably because at least gcc produces terrible amd64 code w/o > > it... It will constantly reload the register it uses to do relative > > loads w/ the same value even though nothing changed... makes > > performance suck... > Well, we are talking about the DEBUG case. So I am not sure if better > performance has more importance than better debugging. And I believe > that -O2 does make debugging harder. On the other hand, the difference between DEBUG and !DEBUG should be minimized to avoid heisenbugs and taking advantage of undefined behaviour that does not work at -O2. Also note that most standard kernel configuration files have the line makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols which suggests that it only adds debug symbols and does not lower the optimization level (even though that is only the case on amd64). So it seems you are asking about lowering the optimization level of almost all amd64 kernels (there seems little reason not to generate .symbols files). In my experience, debugging -O2 code is usually possible with experience, knowledge about compiler optimizations and good compilers and debuggers (for example, gcc and gdb were improved in this area after the switch to GPLv3). It can be rather annoying, though, if there is a lot of inlining or the value of the variable you need is not available (the value may be available elsewhere in the call chain or not at all). -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130804202823.GB39246>