build: Enable flags for better stack traces in non-official CFI builds.

build/common.gypi

 # Copyright (c) 2012 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 # IMPORTANT:
 # Please don't directly include this file if you are building via gyp_chromium,
 # since gyp_chromium is automatically forcing its inclusion.
 {
   # Variables expected to be overriden on the GYP command line (-D) or by
   # ~/.gyp/include.gypi.
@@ skipping 4365 matching lines @@
               '-mstackrealign',
             ],
           }],
           ['clang==1 and "<(GENERATOR)"=="ninja"', {
             'cflags': [
               # See http://crbug.com/110262
               '-fcolor-diagnostics',
             ],
           }],
           # Common options for AddressSanitizer, LeakSanitizer,
-          # ThreadSanitizer and MemorySanitizer.
-          ['asan==1 or lsan==1 or tsan==1 or msan==1 or ubsan==1 or ubsan_vptr==1', {
+          # ThreadSanitizer, MemorySanitizer and non-official CFI builds.
+          ['asan==1 or lsan==1 or tsan==1 or msan==1 or ubsan==1 or ubsan_vptr==1 or '
+           '(cfi_vptr==1 and buildtype!="Official")', {

[Nico, 2015/08/11 22:44:40]

Why is this keyed off buildtype==Official while all the rest now uses cfi_diag?
When do I use which?

[pcc1, 2015/08/11 22:55:10]

We only emit stack traces in release mode when cfi_vptr=1 cfi_diag=0
buildtype!="Official" (see e.g.
https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/r...);
this simply matches that logic. (I guess we could also test for cfi_diag here,
but these particular flags don't matter as much in cfi_diag mode).

             'target_conditions': [
               ['_toolset=="target"', {
                 'cflags': [
                   '-fno-omit-frame-pointer',
                   '-gline-tables-only',
                 ],
                 'cflags!': [
                   '-fomit-frame-pointer',
                 ],
               }],
@@ skipping 1911 matching lines @@
     # settings in target dicts.  SYMROOT is a special case, because many other
     # Xcode variables depend on it, including variables such as
     # PROJECT_DERIVED_FILE_DIR.  When a source group corresponding to something
     # like PROJECT_DERIVED_FILE_DIR is added to a project, in order for the
     # files to appear (when present) in the UI as actual files and not red
     # red "missing file" proxies, the correct path to PROJECT_DERIVED_FILE_DIR,
     # and therefore SYMROOT, needs to be set at the project level.
     'SYMROOT': '<(DEPTH)/xcodebuild',
   },
 }