Re: Building Kernel with -O0

[Andi Kleen <andi@firstfloor.org>]

"Keith A. Prickett" <keithp@marvell.com> writes:
>
> All of this could, potentially be changed by a configuration parameter
> and added into the kernel release.  Does someone have a primer on why
> this kind of behavior is not desired or "possible"?

Traditionally it was not allowed because -O0 didn't inline and
the kernel relied on inlining in some cases. But with always_inline
that is obsolete -- all functions that rely on inlining should be 
marked __always_inline.

I think a few more cases crept in where it was common to write
build time asserts as

      if (some condition the compiler evaluates at runtime)
         __error_condition_xyz_is_false(); 
 
and this obviously relies on the optimizer to build. But these
are all slowly moving over the BUILD_BUG_ON() which also doesn't
rely on the optimizer, so it's also obsolete.

Then there's the issue that some of the kernel macros will
generate absolutely terrible code without optimizer
(good examples are the macros in asm-x86/uaccess.h). But I guess
that could be tolerated too.

Then another reason was that traditionally no source level
debugger was included and if you do assembly level debugging
optimized code is typically easier to read and debug because
the unoptimized gcc code is so terrible.

And with kgdb now being a standard option that has also changed.
And I agree with you that sometimes stepping through code
is very educational. And gdb tends to be a lot happier 
with -O0 code indeed.

So if you can make it all work cleanly, ideally tested on
other architectures too and a bit broader (e.g. with allyesconfig) 
and track down whatever the mm/* issue 
is correctly I don't see any real reason to not submit
a mainline patch that enables this as a CONFIG. Of course
it has to be very clean and not contain hacks.

If you're not familiar with submitting kernel patches
please read Documentation/{SubmittingPatches,SubmitChecklist} 
first.

Hope this helps,

-Andi

-- 
ak@linux.intel.com