[patch] Cleaning up amd64 kernel optimization options
Alexander Best
arundel at freebsd.org
Fri Dec 23 16:00:32 UTC 2011
On Fri Dec 23 11, John Baldwin wrote:
> On Thursday, December 22, 2011 9:51:47 pm Garrett Cooper wrote:
> > On Dec 22, 2011, at 4:59 PM, Alexander Best <arundel at freebsd.org> wrote:
> >
> > > On Thu Dec 22 11, Benjamin Kaduk wrote:
> > >> On Thu, 22 Dec 2011, Alexander Best wrote:
> > >>
> > >>> On Thu Dec 22 11, Dimitry Andric wrote:
> > >>>> Hi,
> > >>>>
> > >>>> I would like to ask some feedback on the attached patch, which cleans up
> > >>>> the kernel optimization options for amd64. This was touched upon
> > >>>> earlier by Alexander Best in freebsd-toolchain, here:
> > >>>
> > >>> i've been using such settings for a few months now and haven't noticed any
> > >>> problems.
> > >>>
> > >>> however bruce evans raised a good point (in a private mail). when you
> > >>> compile a
> > >>> kernel without debugging enabled, -O2 is the default. if you experience
> > >>> issues,
> > >>> and enable debugging, -O0 now becomes the default. in case the problems
> > >>> with
> > >>> the kernel were caused by the -O2 option and aren't present with the -O0
> > >>> option, the newly built kernel with debugging enabled will not help you
> > >>> fix the
> > >>> problems. in that case you would need to set -O2 explicitly in CFLAGS. his
> > >>> exact words were:
> > >>>
> > >>> "
> > >>> I don't like -O2 for anything. However, if it is only a default, it is
> > >>> not a problem provided it can be canceled easily. And for debugging, you
> > >>> want the default to be the same as without debugging, so that (by default)
> > >>> you debug the same code that caused the problem.
> > >>> "
> > >>>
> > >>> however i don't think this is fixable. using -O0 for debuggable and
> > >>> non-debuggable kernels will cause too much of a slowdown.
> > >>>
> > >>> having -O2 as the default flag for non-debuggable kernels and -O2 -g for
> > >>> debuggable kernels might cause situations, where debugging isn't possible,
> > >>> where with -O0 -g it would have been.
> > >>>
> > >>> so i guess although bruces concerns are valid, they are impossible to
> > >>> solve.
> > >>
> > >> Where does -O0 come in? I only see talk of -O (i.e. -O1) versus -O2.
> > >
> > > sorry. of course i meant -O:
> > >
> > > .if defined(DEBUG)
> > > _MINUS_O= -O
> > > CTFFLAGS+= -g
> > > .else
> > > [..]
> >
> > Back in the 7.x days, I ran into some code that wasn't easily to debug because the compiler optimized things out with -O2 by inlining and
> otherwise shifting around code, so setting breakpoints in gdb became difficult. So from that point on I've gotten into the habit of doing -O
> explicitly in make.conf if DEBUG_FLAGS was specified. Just a thought..
>
> I still leave -O2 in, but what I do is this:
>
> make DEBUG_FLAGS="-g -fno-inline"
would making -O2 -fno-inline the default flags introduce any major slowdown?
all that would be needed then to build a debugging kernel would be to add -g.
cheers.
alex
>
> Just adding -fno-inline makes a world of difference.
>
> --
> John Baldwin
More information about the freebsd-current
mailing list