linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.

linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.

This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.

1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster.
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.

There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower. Also,
people were on an older default Ubuntu and used an older gdb version.)

People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.

Remove the explicit gdb_index gn arg now that this has a good default.

2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=374952
R=piman@chromium.org, tansell@chromium.org

Review-Url: https://codereview.chromium.org/2770933009
Cr-Original-Commit-Position: refs/heads/master@{#459790}
Committed: https://chromium.googlesource.com/chromium/src/+/7b26c51270cebd5de672a155b34f30bc8282c35a
Review-Url: https://codereview.chromium.org/2770933009 .
Cr-Commit-Position: refs/heads/master@{#459824}
Committed: https://chromium.googlesource.com/chromium/src/+/b9f7581b93ae8096afed29d415791803caf2e2e3

[Nico, 2017-03-24 23:10:22]

Description was changed from

==========
linux: Make symbol_level=1 (fastbuild=1) builds work again after the gn switch.

In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.  XXX asan

*:

BUG=
==========

to

==========
linux: Make symbol_level=1 (fastbuild=1) debug builds work again after the gn
switch.

In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=none
==========

[Nico, 2017-03-24 23:11:38]

Description was changed from

==========
linux: Make symbol_level=1 (fastbuild=1) debug builds work again after the gn
switch.

In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=none
==========

to

==========
linux: Make symbol_level=1 (fastbuild=1) debug builds work again after the gn
switch.

In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time from 39s to 13s and time from `run` in gdb to the
program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=none
==========

[Nico, 2017-03-24 23:20:40]

Description was changed from

==========
linux: Make symbol_level=1 (fastbuild=1) debug builds work again after the gn
switch.

In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time from 39s to 13s and time from `run` in gdb to the
program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=none
==========

to

==========
linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.

This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.

1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster. 
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.

There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower.)

People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.

2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=374952
==========

[Nico, 2017-03-24 23:20:45]

The CQ bit was checked by thakis@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-24 23:21:16]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Nico, 2017-03-24 23:22:12]

Description was changed from

==========
linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.

This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.

1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster. 
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.

There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower.)

People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.

2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=374952
==========

to

==========
linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.

This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.

1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster. 
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.

There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower. Also,
people were on an older default Ubuntu and used an older gdb version.)

People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.

2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=374952
==========

[Nico, 2017-03-24 23:23:17]

thakis@chromium.org changed reviewers:
+ dpranke@chromium.org

[Nico, 2017-03-24 23:25:27]

The CQ bit was checked by thakis@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-24 23:25:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-24 23:35:04]

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

[commit-bot: I haz the power, 2017-03-24 23:35:05]

Dry run: Try jobs failed on following builders:
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)

[piman, 2017-03-25 00:23:01]

piman@chromium.org changed reviewers:
+ piman@chromium.org

[piman, 2017-03-25 00:23:01]

drive-by lgtm ship it.

[mithro, 2017-03-25 00:37:25]

On 2017/03/25 00:23:01, piman wrote:
> drive-by lgtm ship it.

LGTM -- all this sounds pretty logical.

Couple of random questions;

 * Does --gdb-index and -gsplit-dwarf mean you end up with paths in your binary?
 * Any chance we could enable -g3 -- it allows you to debug things like code
from macro expansions. That was one of my original plans after enabling
-gsplit-dwarf but I never was able to make it stick.

Tim 'mithro' Ansell

[Dirk Pranke, 2017-03-25 00:48:42]

I'm out, so just skimmed this, but there is already a gdb_index GN arg. You
should figure out if that does things differently and consolidate the two.

[Nico, 2017-03-27 14:58:17]

The CQ bit was checked by thakis@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-27 14:58:33]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Nico, 2017-03-27 14:58:39]

Description was changed from

==========
linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.

This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.

1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster. 
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.

There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower. Also,
people were on an older default Ubuntu and used an older gdb version.)

People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.

2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=374952
==========

to

==========
linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.

This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.

1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster. 
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.

There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower. Also,
people were on an older default Ubuntu and used an older gdb version.)

People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.

Remove the explicit gdb_index gn arg now that this has a good default.

2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=374952
==========

[Nico, 2017-03-27 14:58:59]

On 2017/03/25 00:48:42, Dirk Pranke (slow until 28th) wrote:
> I'm out, so just skimmed this, but there is already a gdb_index GN arg. You
> should figure out if that does things differently and consolidate the two.

Ah, thanks for noticing. I removed that now that it has a good default. Fewer
tweakables :-)

[commit-bot: I haz the power, 2017-03-27 15:00:16]

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

[commit-bot: I haz the power, 2017-03-27 15:00:17]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)

[Nico, 2017-03-27 15:02:22]

The CQ bit was checked by thakis@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-27 15:02:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Nico, 2017-03-27 15:21:06]

The CQ bit was unchecked by thakis@chromium.org

[Nico, 2017-03-27 15:21:10]

The CQ bit was checked by thakis@chromium.org

[Nico, 2017-03-27 15:21:11]

The patchset sent to the CQ was uploaded after l-g-t-m from piman@chromium.org,
tansell@chromium.org
Link to the patchset: https://codereview.chromium.org/2770933009/#ps60001
(title: "rebase")

[commit-bot: I haz the power, 2017-03-27 15:21:24]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-27 16:06:19]

CQ is committing da patch.

Bot data: {"patchset_id": 60001, "attempt_start_ts": 1490628070717330,
"parent_rev": "581ff14023b243973f1f722d3ab83115a3f2e991", "commit_rev":
"7b26c51270cebd5de672a155b34f30bc8282c35a"}

[commit-bot: I haz the power, 2017-03-27 16:07:10]

Description was changed from

==========
linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.

This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.

1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster. 
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.

There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower. Also,
people were on an older default Ubuntu and used an older gdb version.)

People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.

Remove the explicit gdb_index gn arg now that this has a good default.

2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=374952
==========

to

==========
linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.

This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.

1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster. 
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.

There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower. Also,
people were on an older default Ubuntu and used an older gdb version.)

People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.

Remove the explicit gdb_index gn arg now that this has a good default.

2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=374952

Review-Url: https://codereview.chromium.org/2770933009
Cr-Commit-Position: refs/heads/master@{#459790}
Committed:
https://chromium.googlesource.com/chromium/src/+/7b26c51270cebd5de672a155b34f...
==========

[commit-bot: I haz the power, 2017-03-27 16:07:11]

Committed patchset #4 (id:60001) as
https://chromium.googlesource.com/chromium/src/+/7b26c51270cebd5de672a155b34f...

[jwd, 2017-03-27 16:29:33]

A revert of this CL (patchset #4 id:60001) has been created in
https://codereview.chromium.org/2776193002/ by jwd@chromium.org.

The reason for reverting is: Suspicion that it cause a compile failure on
https://build.chromium.org/p/chromium.linux/builders/Linux%20Builder%20%28dbg....

[findit-for-me, 2017-03-27 16:34:15]

Findit confirmed this CL at revision 459790 as the culprit for
failures in the build cycles as shown on:
https://findit-for-me.appspot.com/waterfall/culprit?key=ag9zfmZpbmRpdC1mb3Itb...

[Nico, 2017-03-27 17:50:14]

Description was changed from

==========
linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.

This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.

1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster. 
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.

There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower. Also,
people were on an older default Ubuntu and used an older gdb version.)

People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.

Remove the explicit gdb_index gn arg now that this has a good default.

2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=374952

Review-Url: https://codereview.chromium.org/2770933009
Cr-Commit-Position: refs/heads/master@{#459790}
Committed:
https://chromium.googlesource.com/chromium/src/+/7b26c51270cebd5de672a155b34f...
==========

to

==========
linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.

This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.

1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster. 
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.

There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower. Also,
people were on an older default Ubuntu and used an older gdb version.)

People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.

Remove the explicit gdb_index gn arg now that this has a good default.

2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=374952

Review-Url: https://codereview.chromium.org/2770933009
Cr-Commit-Position: refs/heads/master@{#459790}
Committed:
https://chromium.googlesource.com/chromium/src/+/7b26c51270cebd5de672a155b34f...
==========

[Nico, 2017-03-27 17:58:36]

Description was changed from

==========
linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.

This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.

1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster. 
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.

There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower. Also,
people were on an older default Ubuntu and used an older gdb version.)

People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.

Remove the explicit gdb_index gn arg now that this has a good default.

2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=374952

Review-Url: https://codereview.chromium.org/2770933009
Cr-Commit-Position: refs/heads/master@{#459790}
Committed:
https://chromium.googlesource.com/chromium/src/+/7b26c51270cebd5de672a155b34f...
==========

to

==========
linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.

This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.

1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster.
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.

There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower. Also,
people were on an older default Ubuntu and used an older gdb version.)

People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.

Remove the explicit gdb_index gn arg now that this has a good default.

2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.

Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots.  For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.

*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.

BUG=374952
R=piman@chromium.org, tansell@chromium.org

Review-Url: https://codereview.chromium.org/2770933009
Cr-Original-Commit-Position: refs/heads/master@{#459790}
Committed:
https://chromium.googlesource.com/chromium/src/+/7b26c51270cebd5de672a155b34f...
Review-Url: https://codereview.chromium.org/2770933009 .
Cr-Commit-Position: refs/heads/master@{#459824}
Committed:
https://chromium.googlesource.com/chromium/src/+/b9f7581b93ae8096afed29d41579...
==========

[Nico, 2017-03-27 17:58:37]

Committed patchset #5 (id:80001) manually as
b9f7581b93ae8096afed29d415791803caf2e2e3 (presubmit successful).

[sreten.kovacevic, 2017-04-06 09:56:16]

I have a question about this patch. You removed GN arg gdb_index, but wouldn't
it be much nicer solution to set it to true, add it in conditions and that way
make it possible to disable this option in our build.

For example, when compiling v8 on MIPS64 gold linker is not used and --gdb-index
option is not supported, so we are forced to use symbol_level=1, which is not
something we usually want. Also, this way it would be more obvious what is
happening with build, no need to explain what is purpose of specific GN
argument.

[Nico, 2017-04-06 12:06:59]

https://codereview.chromium.org/2791403004/ fixes the problem you're
having, right?

On Apr 6, 2017 5:56 AM, <sreten.kovacevic@imgtec.com> wrote:

> I have a question about this patch. You removed GN arg gdb_index, but
> wouldn't
> it be much nicer solution to set it to true, add it in conditions and that
> way
> make it possible to disable this option in our build.
>
> For example, when compiling v8 on MIPS64 gold linker is not used and
> --gdb-index
> option is not supported, so we are forced to use symbol_level=1, which is
> not
> something we usually want. Also, this way it would be more obvious what is
> happening with build, no need to explain what is purpose of specific GN
> argument.
>
> https://codereview.chromium.org/2770933009/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[sreten.kovacevic, 2017-04-07 09:30:04]

On 2017/04/06 12:06:59, Nico wrote:
> https://codereview.chromium.org/2791403004/ fixes the problem you're
> having, right?
> 
> On Apr 6, 2017 5:56 AM, <mailto:sreten.kovacevic@imgtec.com> wrote:
> 
> > I have a question about this patch. You removed GN arg gdb_index, but
> > wouldn't
> > it be much nicer solution to set it to true, add it in conditions and that
> > way
> > make it possible to disable this option in our build.
> >
> > For example, when compiling v8 on MIPS64 gold linker is not used and
> > --gdb-index
> > option is not supported, so we are forced to use symbol_level=1, which is
> > not
> > something we usually want. Also, this way it would be more obvious what is
> > happening with build, no need to explain what is purpose of specific GN
> > argument.
> >
> > https://codereview.chromium.org/2770933009/
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Chromium-reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

yeah, didn't see the patch, thank you.