Re: [patch] Cleaning up amd64 kernel optimization options

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:
>>=20
>>> On Thu Dec 22 11, Dimitry Andric wrote:
>>>> Hi,
>>>>=20
>>>> I would like to ask some feedback on the attached patch, which cleans u=
p
>>>> the kernel optimization options for amd64.  This was touched upon
>>>> earlier by Alexander Best in freebsd-toolchain, here:
>>>=20
>>> i've been using such settings for a few months now and haven't noticed a=
ny
>>> problems.
>>>=20
>>> however bruce evans raised a good point (in a private mail). when you=20=

>>> compile a
>>> kernel without debugging enabled, -O2 is the default. if you experience=20=

>>> issues,
>>> and enable debugging, -O0 now becomes the default. in case the problems=20=

>>> 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=20=

>>> fix the
>>> problems. in that case you would need to set -O2 explicitly in CFLAGS. h=
is
>>> exact words were:
>>>=20
>>> "
>>> 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, yo=
u
>>> want the default to be the same as without debugging, so that (by defaul=
t)
>>> you debug the same code that caused the problem.
>>> "
>>>=20
>>> however i don't think this is fixable. using -O0 for debuggable and
>>> non-debuggable kernels will cause too much of a slowdown.
>>>=20
>>> having -O2 as the default flag for non-debuggable kernels and -O2 -g for=

>>> debuggable kernels might cause situations, where debugging isn't possibl=
e,
>>> where with -O0 -g it would have been.
>>>=20
>>> so i guess although bruces concerns are valid, they are impossible to=20=

>>> solve.
>>=20
>> Where does -O0 come in?  I only see talk of -O (i.e. -O1) versus -O2.
>=20
> sorry. of course i meant -O:
>=20
> .if defined(DEBUG)
> _MINUS_O=3D       -O
> CTFFLAGS+=3D      -g
> .else
> [..]

Back in the 7.x days, I ran into some code that wasn't easily to debug becau=
se the compiler optimized things out with -O2 by inlining and otherwise shif=
ting around code, so setting breakpoints in gdb became difficult. So from th=
at point on I've gotten into the habit of doing -O explicitly in make.conf i=
f DEBUG_FLAGS was specified. Just a thought..
-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"