Re: [patch] Cleaning up amd64 kernel optimization options


On Fri, Dec 23, 2011 at 12:34 PM, Garrett Cooper <yanegomi@gmail.com> wrote=
:
> On Fri, Dec 23, 2011 at 6:37 AM, John Baldwin <jhb@freebsd.org> wrote:
>> On Thursday, December 22, 2011 9:51:47 pm Garrett Cooper wrote:
>>> On Dec 22, 2011, at 4:59 PM, Alexander Best <arundel@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 cle=
ans up
>>> >>>> the kernel optimization options for amd64. =A0This was touched upo=
n
>>> >>>> earlier by Alexander Best in freebsd-toolchain, here:
>>> >>>
>>> >>> i've been using such settings for a few months now and haven't noti=
ced any
>>> >>> problems.
>>> >>>
>>> >>> however bruce evans raised a good point (in a private mail). when y=
ou
>>> >>> compile a
>>> >>> kernel without debugging enabled, -O2 is the default. if you experi=
ence
>>> >>> issues,
>>> >>> and enable debugging, -O0 now becomes the default. in case the prob=
lems
>>> >>> with
>>> >>> the kernel were caused by the -O2 option and aren't present with th=
e -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 CFLA=
GS. his
>>> >>> exact words were:
>>> >>>
>>> >>> "
>>> >>> I don't like -O2 for anything. =A0However, if it is only a default,=
 it is
>>> >>> not a problem provided it can be canceled easily. =A0And for debugg=
ing, you
>>> >>> want the default to be the same as without debugging, so that (by d=
efault)
>>> >>> 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 po=
ssible,
>>> >>> 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? =A0I only see talk of -O (i.e. -O1) versus -=
O2.
>>> >
>>> > sorry. of course i meant -O:
>>> >
>>> > .if defined(DEBUG)
>>> > _MINUS_O=3D =A0 =A0 =A0 -O
>>> > CTFFLAGS+=3D =A0 =A0 =A0-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 dif=
ficult. 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:
>>
>> =A0make DEBUG_FLAGS=3D"-g -fno-inline"
>>
>> Just adding -fno-inline makes a world of difference.
>
> Sweet -- thanks for the tip ;).

    Just as a sidenote, this option doesn't work when compiling
mii(4), re(4), etc [as modules at least].
Thanks,
-Garrett
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"