Enable debug fission for Chrome debug builds.

This change helps with two significant problems with Chrome debug
builds,
 * Slow link times.
 * Slow gdb startup times.

Lots more detailed information at http://gcc.gnu.org/wiki/DebugFission

Overall, this improves linking speed of debug Chrome builds on Linux
by ~12% and speeds up gdb by around 30%.

This requires a objcopy with --extract-dwo object (binutils newer then
2.22.52.0.4 // 2.23). Ubuntu Precise only comes with 2.22

BUG=352046
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=257424

[mithro-old, 2014-03-16 10:49:52]

Heyo!

Here are is the patches for Chrome related to enabling debug fission change.

[mithro-old, 2014-03-16 10:52:05]

Heyo!

Here are is the patches for Chrome related to enabling debug fission change.

See https://code.google.com/p/chromium/issues/detail?id=352046 for the full list
of bugs.

Tim

[Nico, 2014-03-17 09:07:38]

https://codereview.chromium.org/197013010/diff/20001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/197013010/diff/20001/build/common.gypi#newcod...
build/common.gypi:3093: 'ldflags': ['-Wl,--gdb-index'],
Is there some way we can get this to pick up all the required custom binutils
bits from your other CL? For gold, I think we add -Bpath/to/gold to ldflags,
would something like that work?

[mithro-old, 2014-03-17 09:22:32]

On 2014/03/17 09:07:38, Nico (on GMT time Mar 15 - 24) wrote:
> https://codereview.chromium.org/197013010/diff/20001/build/common.gypi
> File build/common.gypi (right):
> 
>
https://codereview.chromium.org/197013010/diff/20001/build/common.gypi#newcod...
> build/common.gypi:3093: 'ldflags': ['-Wl,--gdb-index'],
> Is there some way we can get this to pick up all the required custom binutils
> bits from your other CL? For gold, I think we add -Bpath/to/gold to ldflags,
> would something like that work?

That is what https://codereview.chromium.org/196573022/ does (it passes -B as
you describe).

[Nico, 2014-03-17 09:42:39]

Cool, lgtm then.

https://codereview.chromium.org/197013010/diff/20001/build/compiler_version.py
File build/compiler_version.py (right):

https://codereview.chromium.org/197013010/diff/20001/build/compiler_version.p...
build/compiler_version.py:33: version_re = re.compile(r"GNU [^ ]+ \(.*\)
(\d+).(\d+)")
Both linker and assembler are assume gcc and gold. Since this file is in build,
not build/linux, that seems not ideal to me. With clang, the -Xassembler
-version bit just prints regular the regular clang version (probably since it
uses an integrated assembler, but it does that with -fno-integrated-as too). On
OS X, ld64 complains "ld: unknown option: --version".

I guess the gcc bit is linux-specific too, so I suppose it's fine, but maybe
this file should move to build/linux.

[Nico, 2014-03-17 09:42:53]

https://codereview.chromium.org/197013010/diff/20001/build/compiler_version.py
File build/compiler_version.py (right):

https://codereview.chromium.org/197013010/diff/20001/build/compiler_version.p...
build/compiler_version.py:33: version_re = re.compile(r"GNU [^ ]+ \(.*\)
(\d+).(\d+)")
On 2014/03/17 09:42:39, Nico (on GMT time Mar 15 - 24) wrote:
> Both linker and assembler are assume gcc and gold. Since this file is in
build,
> not build/linux, that seems not ideal to me. With clang, the -Xassembler
> -version bit just prints regular the regular clang version (probably since it
> uses an integrated assembler, but it does that with -fno-integrated-as too).
On
> OS X, ld64 complains "ld: unknown option: --version".
> 
> I guess the gcc bit is linux-specific too, so I suppose it's fine, but maybe
> this file should move to build/linux.

(Not in this cl.)

[Nico, 2014-03-17 10:14:40]

Actually: Does this do the right thing for cross builds (say android), if only
the host (more likely) or only the target toolchain supports fission?

[mithro-old, 2014-03-17 10:36:20]

On 2014/03/17 10:14:40, Nico (on GMT time Mar 15 - 24) wrote:
> Actually: Does this do the right thing for cross builds (say android), if only
> the host (more likely) or only the target toolchain supports fission.

Not sure. I don't think debug fission is arch dependent? 

Currently android builds hard code a gcc version of 46. I also added a hardcode
of binutils 222. Both these disable debug fission.

No idea about other archs?

https://codereview.chromium.org/197013010/diff/20001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/197013010/diff/20001/build/common.gypi#newcod...
build/common.gypi:3093: 'ldflags': ['-Wl,--gdb-index'],
On 2014/03/17 09:07:38, Nico (on GMT time Mar 15 - 24) wrote:
> Is there some way we can get this to pick up all the required custom binutils
> bits from your other CL? For gold, I think we add -Bpath/to/gold to ldflags,
> would something like that work?

See https://codereview.chromium.org/196573022/ which does exactly this.

https://codereview.chromium.org/197013010/diff/20001/build/compiler_version.py
File build/compiler_version.py (right):

https://codereview.chromium.org/197013010/diff/20001/build/compiler_version.p...
build/compiler_version.py:33: version_re = re.compile(r"GNU [^ ]+ \(.*\)
(\d+).(\d+)")
On 2014/03/17 09:42:39, Nico (on GMT time Mar 15 - 24) wrote:
> Both linker and assembler are assume gcc and gold. Since this file is in
build,
> not build/linux, that seems not ideal to me. With clang, the -Xassembler
> -version bit just prints regular the regular clang version (probably since it
> uses an integrated assembler, but it does that with -fno-integrated-as too).

It appears our clang version (clang version 3.5 trunk 198389) doesn't yet
support -fno-integrated-as, only the older -no-integrated-as. When giving
-no-integrated-as it seems to work fine.

-----------------------------------------------------------------
tansell@tansell-z620-l2:/fast/chrome/src$
CXX="third_party/llvm-build/Release+Asserts/bin/clang++
-Bthird_party/binutils/x86_64-unknown-linux-gnu/bin" python
./build/compiler_version.py assembler
clang: error: unsupported argument '--version' to option 'Xassembler'
compiler_version.py failed to execute:
third_party/llvm-build/Release+Asserts/bin/clang++
-Bthird_party/binutils/x86_64-unknown-linux-gnu/bin -Xassembler --version -x
assembler -c /dev/null
Command 'third_party/llvm-build/Release+Asserts/bin/clang++
-Bthird_party/binutils/x86_64-unknown-linux-gnu/bin -Xassembler --version -x
assembler -c /dev/null' returned non-zero exit status 1
-----------------------------------------------------------------
tansell@tansell-z620-l2:/fast/chrome/src$
CXX="third_party/llvm-build/Release+Asserts/bin/clang++
-Bthird_party/binutils/x86_64-unknown-linux-gnu/bin -fno-integrated-as" python
./build/compiler_version.py assembler
clang: error: unknown argument: '-fno-integrated-as'
clang: error: unsupported argument '--version' to option 'Xassembler'
compiler_version.py failed to execute:
third_party/llvm-build/Release+Asserts/bin/clang++
-Bthird_party/binutils/x86_64-unknown-linux-gnu/bin -fno-integrated-as
-Xassembler --version -x assembler -c /dev/null
Command 'third_party/llvm-build/Release+Asserts/bin/clang++
-Bthird_party/binutils/x86_64-unknown-linux-gnu/bin -fno-integrated-as
-Xassembler --version -x assembler -c /dev/null' returned non-zero exit status 1
-----------------------------------------------------------------
tansell@tansell-z620-l2:/fast/chrome/src$
CXX="third_party/llvm-build/Release+Asserts/bin/clang++
-Bthird_party/binutils/x86_64-unknown-linux-gnu/bin -no-integrated-as" python
./build/compiler_version.py assembler
224
-----------------------------------------------------------------

> On
> OS X, ld64 complains "ld: unknown option: --version".

The linker target works fine with clang.

-----------------------------------------------------------------
tansell@tansell-z620-l2:/fast/chrome/src$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.22
...
-----------------------------------------------------------------
tansell@tansell-z620-l2:/fast/chrome/src$
CXX="third_party/llvm-build/Release+Asserts/bin/clang++" python
./build/compiler_version.py linker
222
-----------------------------------------------------------------
tansell@tansell-z620-l2:/fast/chrome/src$
third_party/binutils/x86_64-unknown-linux-gnu/bin/ld --version
GNU gold (GNU Binutils 2.24) 1.11
...
-----------------------------------------------------------------
tansell@tansell-z620-l2:/fast/chrome/src$
CXX="third_party/llvm-build/Release+Asserts/bin/clang++
-Bthird_party/binutils/x86_64-unknown-linux-gnu/bin" python
./build/compiler_version.py linker
111
-----------------------------------------------------------------

> I guess the gcc bit is linux-specific too, so I suppose it's fine, but maybe
> this file should move to build/linux.

Surprisingly the compiler section is not specific to gcc but is still kind of
strange...

-----------------------------------------------------------------
tansell@tansell-z620-l2:/fast/chrome/src$ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
tansell@tansell-z620-l2:/fast/chrome/src$ gcc -dumpversion
4.6
tansell@tansell-z620-l2:/fast/chrome/src$
-----------------------------------------------------------------
tansell@tansell-z620-l2:/fast/chrome/src$
third_party/llvm-build/Release+Asserts/bin/clang++ --version
clang version 3.5 (trunk 198389)
Target: x86_64-unknown-linux-gnu
Thread model: posix
tansell@tansell-z620-l2:/fast/chrome/src$
third_party/llvm-build/Release+Asserts/bin/clang++ -dumpversion
4.2.1
tansell@tansell-z620-l2:/fast/chrome/src$
-----------------------------------------------------------------

compiler_version.py only does seem to be used on Linux though,

 1297       ['os_posix==1 and OS!="mac" and OS!="ios" and clang==0 and asan==0
and lsan==0 and tsan==0 and msan==0', {

[Nico, 2014-03-17 10:53:05]

On Mon, Mar 17, 2014 at 10:36 AM, <mithro@mithis.com> wrote:

> On 2014/03/17 10:14:40, Nico (on GMT time Mar 15 - 24) wrote:
>
>> Actually: Does this do the right thing for cross builds (say android), if
>> only
>> the host (more likely) or only the target toolchain supports fission.
>>
>
> Not sure. I don't think debug fission is arch dependent?
>
> Currently android builds hard code a gcc version of 46. I also added a
> hardcode
> of binutils 222. Both these disable debug fission.
>

Ok. In theory, we could use fission for the host binaries still, but that's
very likely not worth it. So sounds good as-is for now.


>
> No idea about other archs?
>
>
>
> https://codereview.chromium.org/197013010/diff/20001/build/common.gypi
> File build/common.gypi (right):
>
> https://codereview.chromium.org/197013010/diff/20001/
> build/common.gypi#newcode3093
> build/common.gypi:3093: 'ldflags': ['-Wl,--gdb-index'],
> On 2014/03/17 09:07:38, Nico (on GMT time Mar 15 - 24) wrote:
>
>> Is there some way we can get this to pick up all the required custom
>>
> binutils
>
>> bits from your other CL? For gold, I think we add -Bpath/to/gold to
>>
> ldflags,
>
>> would something like that work?
>>
>
> See https://codereview.chromium.org/196573022/ which does exactly this.
>
>
> https://codereview.chromium.org/197013010/diff/20001/
> build/compiler_version.py
> File build/compiler_version.py (right):
>
> https://codereview.chromium.org/197013010/diff/20001/
> build/compiler_version.py#newcode33
> build/compiler_version.py:33: version_re = re.compile(r"GNU [^ ]+ \(.*\)
> (\d+).(\d+)")
> On 2014/03/17 09:42:39, Nico (on GMT time Mar 15 - 24) wrote:
>
>> Both linker and assembler are assume gcc and gold. Since this file is
>>
> in build,
>
>> not build/linux, that seems not ideal to me. With clang, the
>>
> -Xassembler
>
>> -version bit just prints regular the regular clang version (probably
>>
> since it
>
>> uses an integrated assembler, but it does that with -fno-integrated-as
>>
> too).
>
> It appears our clang version (clang version 3.5 trunk 198389) doesn't
> yet support -fno-integrated-as, only the older -no-integrated-as. When
> giving -no-integrated-as it seems to work fine.
>
> -----------------------------------------------------------------
> tansell@tansell-z620-l2:/fast/chrome/src$
> CXX="third_party/llvm-build/Release+Asserts/bin/clang++
> -Bthird_party/binutils/x86_64-unknown-linux-gnu/bin" python
> ./build/compiler_version.py assembler
> clang: error: unsupported argument '--version' to option 'Xassembler'
> compiler_version.py failed to execute:
> third_party/llvm-build/Release+Asserts/bin/clang++
> -Bthird_party/binutils/x86_64-unknown-linux-gnu/bin -Xassembler
>
> --version -x assembler -c /dev/null
> Command 'third_party/llvm-build/Release+Asserts/bin/clang++
> -Bthird_party/binutils/x86_64-unknown-linux-gnu/bin -Xassembler
> --version -x assembler -c /dev/null' returned non-zero exit status 1
> -----------------------------------------------------------------
> tansell@tansell-z620-l2:/fast/chrome/src$
> CXX="third_party/llvm-build/Release+Asserts/bin/clang++
> -Bthird_party/binutils/x86_64-unknown-linux-gnu/bin -fno-integrated-as"
> python ./build/compiler_version.py assembler
> clang: error: unknown argument: '-fno-integrated-as'
> clang: error: unsupported argument '--version' to option 'Xassembler'
> compiler_version.py failed to execute:
> third_party/llvm-build/Release+Asserts/bin/clang++
> -Bthird_party/binutils/x86_64-unknown-linux-gnu/bin -fno-integrated-as
>
> -Xassembler --version -x assembler -c /dev/null
> Command 'third_party/llvm-build/Release+Asserts/bin/clang++
> -Bthird_party/binutils/x86_64-unknown-linux-gnu/bin -fno-integrated-as
> -Xassembler --version -x assembler -c /dev/null' returned non-zero exit
> status 1
> -----------------------------------------------------------------
> tansell@tansell-z620-l2:/fast/chrome/src$
> CXX="third_party/llvm-build/Release+Asserts/bin/clang++
> -Bthird_party/binutils/x86_64-unknown-linux-gnu/bin -no-integrated-as"
> python ./build/compiler_version.py assembler
> 224
> -----------------------------------------------------------------
>
>
>  On
>> OS X, ld64 complains "ld: unknown option: --version".
>>
>
> The linker target works fine with clang.
>

If the linker supports --version. ld64, OS X's linker (which is why I wrote
"On OS X", not "with clang") doesn't.


>
> -----------------------------------------------------------------
> tansell@tansell-z620-l2:/fast/chrome/src$ ld --version
> GNU ld (GNU Binutils for Ubuntu) 2.22
> ...
> -----------------------------------------------------------------
> tansell@tansell-z620-l2:/fast/chrome/src$
> CXX="third_party/llvm-build/Release+Asserts/bin/clang++" python
> ./build/compiler_version.py linker
> 222
> -----------------------------------------------------------------
> tansell@tansell-z620-l2:/fast/chrome/src$
> third_party/binutils/x86_64-unknown-linux-gnu/bin/ld --version
> GNU gold (GNU Binutils 2.24) 1.11
> ...
> -----------------------------------------------------------------
> tansell@tansell-z620-l2:/fast/chrome/src$
> CXX="third_party/llvm-build/Release+Asserts/bin/clang++
> -Bthird_party/binutils/x86_64-unknown-linux-gnu/bin" python
> ./build/compiler_version.py linker
> 111
> -----------------------------------------------------------------
>
>
>  I guess the gcc bit is linux-specific too, so I suppose it's fine, but
>>
> maybe
>
>> this file should move to build/linux.
>>
>
> Surprisingly the compiler section is not specific to gcc but is still
> kind of strange...
>
> -----------------------------------------------------------------
> tansell@tansell-z620-l2:/fast/chrome/src$ gcc --version
> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is
> NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> tansell@tansell-z620-l2:/fast/chrome/src$ gcc -dumpversion
> 4.6
> tansell@tansell-z620-l2:/fast/chrome/src$
> -----------------------------------------------------------------
> tansell@tansell-z620-l2:/fast/chrome/src$
> third_party/llvm-build/Release+Asserts/bin/clang++ --version
> clang version 3.5 (trunk 198389)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> tansell@tansell-z620-l2:/fast/chrome/src$
> third_party/llvm-build/Release+Asserts/bin/clang++ -dumpversion
> 4.2.1
> tansell@tansell-z620-l2:/fast/chrome/src$
> -----------------------------------------------------------------
>
> compiler_version.py only does seem to be used on Linux though,
>

Right, that's why I said it should probably move to build/linux.


>
>  1297       ['os_posix==1 and OS!="mac" and OS!="ios" and clang==0 and
> asan==0 and lsan==0 and tsan==0 and msan==0', {
>
> https://codereview.chromium.org/197013010/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[mithro-old, 2014-03-17 11:28:34]

The CQ bit was checked by mithro@mithis.com

[commit-bot: I haz the power, 2014-03-17 11:28:43]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mithro@mithis.com/197013010/40001

[commit-bot: I haz the power, 2014-03-17 12:38:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-17 12:38:09]

Try jobs failed on following builders:
  tryserver.chromium on mac_chromium_rel

[mithro-old, 2014-03-17 12:47:44]

The CQ bit was checked by mithro@mithis.com

[commit-bot: I haz the power, 2014-03-17 12:48:02]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mithro@mithis.com/197013010/40001

[commit-bot: I haz the power, 2014-03-17 14:11:23]

Change committed as 257424

[Lei Zhang, 2014-03-17 18:43:53]

https://codereview.chromium.org/197013010/diff/40001/build/compiler_version.py
File build/compiler_version.py (right):

https://codereview.chromium.org/197013010/diff/40001/build/compiler_version.p...
build/compiler_version.py:58: print "Unknown arguments!"
Probably should return 1 in this case?

[Inactive, 2014-03-17 18:57:28]

Starting today, I am getting linking errors on Linux Desktop, could it be
related to this change?

Error:
http://pastebin.com/w96zJPSy

[Inactive, 2014-03-17 18:59:17]

On 2014/03/17 18:57:28, Chris Dumez wrote:
> Starting today, I am getting linking errors on Linux Desktop, could it be
> related to this change?
> 
> Error:
> http://pastebin.com/w96zJPSy

Note that these linking warning are not new. However, they were not treated as
errors until today.

[Lei Zhang, 2014-03-17 19:01:44]

On 2014/03/17 18:59:17, Chris Dumez wrote:
> On 2014/03/17 18:57:28, Chris Dumez wrote:
> > Starting today, I am getting linking errors on Linux Desktop, could it be
> > related to this change?
> > 
> > Error:
> > http://pastebin.com/w96zJPSy
> 
> Note that these linking warning are not new. However, they were not treated as
> errors until today.

Chris: It's pretty easy to revert this CL, re-run gyp and see if it makes a
difference.

[Nico, 2014-03-18 00:16:48]

Chris: No, that's from r257419 (see
http://svnsearch.org/svnsearch/repos/CHROMIUM/search?author=jochen@chromium.o...
a few follow-ups).


On Mon, Mar 17, 2014 at 7:01 PM, <thestig@chromium.org> wrote:

> On 2014/03/17 18:59:17, Chris Dumez wrote:
>
>> On 2014/03/17 18:57:28, Chris Dumez wrote:
>> > Starting today, I am getting linking errors on Linux Desktop, could it
>> be
>> > related to this change?
>> >
>> > Error:
>> > http://pastebin.com/w96zJPSy
>>
>
>  Note that these linking warning are not new. However, they were not
>> treated as
>> errors until today.
>>
>
> Chris: It's pretty easy to revert this CL, re-run gyp and see if it makes a
> difference.
>
> https://codereview.chromium.org/197013010/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Adam Goode, 2014-03-18 03:18:39]

On 2014/03/18 00:16:48, Nico (on GMT time Mar 15 - 24) wrote:
> Chris: No, that's from r257419 (see
>
http://svnsearch.org/svnsearch/repos/CHROMIUM/search?author=jochen%40chromium...
> a few follow-ups).
> 
> 
> On Mon, Mar 17, 2014 at 7:01 PM, <mailto:thestig@chromium.org> wrote:
> 
> > On 2014/03/17 18:59:17, Chris Dumez wrote:
> >
> >> On 2014/03/17 18:57:28, Chris Dumez wrote:
> >> > Starting today, I am getting linking errors on Linux Desktop, could it
> >> be
> >> > related to this change?
> >> >
> >> > Error:
> >> > http://pastebin.com/w96zJPSy
> >>
> >
> >  Note that these linking warning are not new. However, they were not
> >> treated as
> >> errors until today.
> >>
> >
> > Chris: It's pretty easy to revert this CL, re-run gyp and see if it makes a
> > difference.
> >
> > https://codereview.chromium.org/197013010/
> >
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

This seems to break on Fedora:
https://code.google.com/p/chromium/issues/detail?id=353433

[Daniel Bratell, 2014-03-18 10:06:03]

The commit message says "Ubuntu Precise only comes with 2.23". I think you meant
2.22, because that is what is available in the repos for 12.04 LTS (Precise).

[mithro-old, 2014-03-18 10:13:56]

Sorry, yes you are correct. I updated my local commit message but forgot to
update codereview :/

Tim


On 18 March 2014 21:06, <bratell@opera.com> wrote:

> The commit message says "Ubuntu Precise only comes with 2.23". I think you
> meant
> 2.22, because that is what is available in the repos for 12.04 LTS
> (Precise).
>
>
> https://codereview.chromium.org/197013010/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[ostap, 2014-03-18 16:00:05]

https://codereview.chromium.org/197013010/diff/40001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/197013010/diff/40001/build/common.gypi#newcod...
build/common.gypi:3092: ['linux_use_gold_flags==1 and (clang==1 or
gcc_version>=47) and binutils_version>=223', {
I have gold 1.11, binutils 2.23.2 and gcc 4.7.3 on ubuntu 13.04 .
Unfortunately getting errors:
cc1: error: unrecognised debug output level "split-dwarf"

gcc/g++ man also doesn't have this option listed.

However on Ubuntu 13.10 with gcc 4.8.1 this option exists.
It think gcc version check should be changed to gcc_version>=48 to make it work
for sure.

[Nico, 2014-03-18 16:01:10]

A fix for the 4.7 problem is in the CQ here:
https://codereview.chromium.org/203133003/


On Tue, Mar 18, 2014 at 4:00 PM, <sl.ostapenko@samsung.com> wrote:

>
> https://codereview.chromium.org/197013010/diff/40001/build/common.gypi
> File build/common.gypi (right):
>
> https://codereview.chromium.org/197013010/diff/40001/
> build/common.gypi#newcode3092
> build/common.gypi:3092: ['linux_use_gold_flags==1 and (clang==1 or
>
> gcc_version>=47) and binutils_version>=223', {
> I have gold 1.11, binutils 2.23.2 and gcc 4.7.3 on ubuntu 13.04 .
> Unfortunately getting errors:
> cc1: error: unrecognised debug output level "split-dwarf"
>
> gcc/g++ man also doesn't have this option listed.
>
> However on Ubuntu 13.10 with gcc 4.8.1 this option exists.
> It think gcc version check should be changed to gcc_version>=48 to make
> it work for sure.
>
> https://codereview.chromium.org/197013010/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Nico, 2014-04-10 18:15:38]

(re cl description: Always include the "title" line as first line in the
description too, as only the description makes it into the commit message. The
commit message is now missing "Enable debug fission for Chrome debug builds."
which makes it sound a bit incomplete.)