Commit 58d554bd authored by Takuto Ikuta's avatar Takuto Ikuta Committed by Commit Bot

Do not include debug symbol for faster link time on linux buildbot

-g0 flag reduces size of some large test files
* components_unittests from 918MB to 206MB
* unit_tests from 1023MB to 258MB
with args.gn of linux_chromium_rel_ng.

Current linux buildbot is GCE VM running with 500GB persistent disk which has 60MB/s write throughput.
https://cloud.google.com/compute/docs/disks/#introduction
This IOPS limit affects link step necessary to write large binaries on buildbot.
This patch is for speed up link by reducing binary size written to disk on buildbot.

I assumed followings for symbol configs
* no_symbols: no guarantee of amount of symbol.
* minimal_symbols: include symbols to show function name in stack trace.
* symbols: include symbols used for debugger.


## FAQ

- Does this keep symbols, function name, file path and line number necessary for stacktrace?

  Partially yes.
  Symbols for function is stored in symbol table, which are not removed unless we pass -Wl,--strip-all to linker.
  File path and line number of function are not shown in stack trace when unittests crashes,
  but it is true even when we use is_debug=true and symbol_level=2.
  File path and line number have been shown only for detected failure in lsan/asan builder.
  https://clang.llvm.org/docs/ThreadSanitizer.html#usage


- How much amount binary size is reduced?

  Without this patch, building all generates 65GB binary.
  $ ls -aSl out/linux_chromium_rel_ng/ | tail -n +1 | awk '{sum += $5}END{print sum/1024/1024 "MB"}'
  65673.4MB

  With -g0, building all generates 14GB binary.
  $ ls -aSl out/linux_chromium_rel_ng/ | tail -n +1 | awk '{sum += $5}END{print sum/1024/1024 "MB"}'
  14602MB


- How fast link step will be?

  I show some ninja traces for link time comparison
  ninja build trace shows that this flag improves link time of some large binaries.
  trace from this patch: https://chromium-build-stats.appspot.com/ninja_log/2018/01/25/slave645-c4/ninja_log.slave645-c4.chrome-bot.20180125-034227.4651.gz/trace.html

  - taken from https://ci.chromium.org/buildbot/tryserver.chromium.linux/linux_chromium_rel_ng/630949
    https://chromium-build-stats.appspot.com/ninja_log/2018/01/24/slave287-c4/ninja_log.slave287-c4.chrome-bot.20180123-214259.6113.gz/trace.html

  - taken from https://ci.chromium.org/buildbot/tryserver.chromium.linux/linux_chromium_rel_ng/630946
    https://chromium-build-stats.appspot.com/ninja_log/2018/01/24/slave182-c4/ninja_log.slave182-c4.chrome-bot.20180123-213611.16740.gz/trace.html

  I estimate this CL reduces the duration of link time from around 400s to 100s on linux_chromium_rel_ng.

Bug: 794423
Change-Id: Id840df30b90e3ac177004edb5c1673a6d8e9b3ca
Reviewed-on: https://chromium-review.googlesource.com/826842
Commit-Queue: Takuto Ikuta <tikuta@google.com>
Reviewed-by: default avatarDirk Pranke <dpranke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532334}
parent 6ac9e7c7
......@@ -2007,6 +2007,8 @@ config("symbols") {
}
# Minimal symbols.
# This config guarantees to hold symbol for stack trace which are shown to user
# when crash happens in unittests running on buildbot.
config("minimal_symbols") {
if (is_win) {
# Linker symbols for backtraces only.
......@@ -2019,7 +2021,16 @@ config("minimal_symbols") {
# TODO(thakis): Remove this again once dump_syms is fixed.
cflags += [ "-gdwarf-3" ]
}
cflags += [ "-g1" ]
if (is_linux && !using_sanitizer) {
# minimal_symbols needs to only produce valid stack traces, and -g0 does
# that, even though you might think it'd produce no symbols at all.
# Not using -g1 allows us to speed up link time and save disk space.
cflags += [ "-g0" ]
} else {
# If sanitizer detects some failure, symbolizer tries to show files and
# line number from debug symbols.
cflags += [ "-g1" ]
}
ldflags = []
if (is_android && is_clang) {
# Android defaults to symbol_level=1 builds in production builds
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment