Add a way to override optimization level for debug builds on Linux

Add a new option, debug_optimize, that lets you set the
optimization level used for debug builds on linux.  
They still default to -O0, but you can set them to -O1 by
doing 'gyp -Ddebug_optimize=1'.
This cuts valgrind runtime without screwing up stack dumps too badly.
On the buildbot, the easiest way to use this is to 
create the file ~/.gyp/include.gypi by hand, containing the lines

# Override for valgrind buildbot
{
 'variables': {
   'debug_optimize': '1',
 },
}

From then on, any "gclient sync" run, when it runs gyp after finishing,
will cause debug builds to use -O1.  This is a bit obscure, but
it's a heck of a lot easier than threading some flag value
through the buildbot scripts or adding a new build mode.


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=14046

[dank, 2009-04-16 02:14:40]

I'm just guessing here, but it does seem to work on linux...

[Mark Mentovai, 2009-04-16 16:45:48]

Aside from not being in love with the name OptDebug, which is no big deal, we
can choose something better...

I'm very much on the fence for this one.  I really want to minimize the number
of configurations and variants and weird corner cases.  Every new tunable we add
gives us more opportunities for things to go wrong and thins out testing on the
configurations that we do have.

I understand the motivation here - a compromise between quicker valgrind
turnaround and usable backtraces, so I'd be willing to make an exception for
this, but I want to know what your plans here are.  Do you want to replace
existing debug or release valgrind test bots with this?  I think that if we do
anything, it should be supplementary.  It's important to test debug even if slow
because it's likely to catch latent bugs that other modes might optimize away,
and it's important to test release even if the backtraces suck because it's
closest to what ships.  If we had a renamed OptDebug, I'd view it as something
that might catch some -O0 memory errors but faster, and something that might
catch some -O2/-Os memory errors but with better stacks, but not a complete
replacement for either.  Do you agree?

[dank, 2009-04-17 22:44:21]

switched to gyp magic

[Mark Mentovai, 2009-04-20 19:06:54]

LG with a comment.

http://codereview.chromium.org/67199/diff/6/2002
File build/common.gypi (right):

http://codereview.chromium.org/67199/diff/6/2002#newcode247
Line 247: '-O2',
I suggest doing -O<(debug_optimize) here too, and providing a default of '2' in
this section the way you have '0' for Debug.

[dank, 2009-04-20 19:10:21]

I tried that, but ran into trouble.  I'm happier keeping the patch minimal for
the moment.  We can easily generalize later.