Start landing build support for Clang-style ASan on Windows

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 1062 matching lines @@
     # The default settings for third party code for treating
     # warnings-as-errors. Ideally, this would not be required, however there
     # is some third party code that takes a long time to fix/roll. So, this
     # flag allows us to have warnings as errors in general to prevent
     # regressions in most modules, while working on the bits that are
     # remaining.
     'win_third_party_warn_as_error%': 'true',
 
     # Clang stuff.
     'clang%': '<(clang)',
-    'make_clang_dir%': 'third_party/llvm-build/Release+Asserts',
+    'make_clang_dir%': '<!(python -c "import sys, os; print os.path.abspath(sys.argv[1])" <(DEPTH)/third_party/llvm-build/Release+Asserts)',

[Timur Iskhodzhanov, 2014/02/13 09:18:30]

Maybe want to add a comment explaining why absolute paths are needed.

 
     # These two variables can be set in GYP_DEFINES while running
     # |gclient runhooks| to let clang run a plugin in every compilation.
     # Only has an effect if 'clang=1' is in GYP_DEFINES as well.
     # Example:
     #     GYP_DEFINES='clang=1 clang_load=/abs/path/to/libPrintFunctionNames.dylib clang_add_plugin=print-fns' gclient runhooks
 
     'clang_load%': '',
     'clang_add_plugin%': '',
 
@@ skipping 478 matching lines @@
             'winsdk_arch%': 'x86',
           },{
             'winsdk_arch%': '<(target_arch)',
           }],
           ['component=="shared_library"', {
             'win_use_allocator_shim%': 0,
           },{
             # Turn on multiple dll by default on Windows when in static_library.
             'chrome_multiple_dll%': 1,
           }],
+          ['clang==1 and asan==1', {
+            'win_use_allocator_shim%': 0,
+          }],
           ['component=="shared_library" and "<(GENERATOR)"=="ninja"', {
             # Only enabled by default for ninja because it's buggy in VS.
             # Not enabled for component=static_library because some targets
             # are too large and the toolchain fails due to the size of the
             # .obj files.
             'incremental_chrome_dll%': 1,
           }],
           # Don't do incremental linking for large modules on 32-bit or when
           # component=static_library as the toolchain fails due to the size of
           # the .ilk files.
@@ skipping 722 matching lines @@
       ['use_openssl==1', {
         'defines': [
           'USE_OPENSSL=1',
         ],
       }],
       ['enable_eglimage==1', {
         'defines': [
           'ENABLE_EGLIMAGE=1',
         ],
       }],
-      ['asan==1 and OS=="win"', {
-        # Since asan on windows uses Syzygy, we need /PROFILE turned on to
+      ['asan==1 and OS=="win" and clang!=1', {
+        # For SyzyAsan, we need /PROFILE turned on to
         # produce appropriate pdbs.
         'msvs_settings': {
           'VCLinkerTool': {
             'Profile': 'true',
           },
         },
         'defines': [
             'ADDRESS_SANITIZER',
             'MEMORY_TOOL_REPLACES_ALLOCATOR',
         ],
@@ skipping 2384 matching lines @@
                 }],
                 ['MSVS_VERSION=="2010" or MSVS_VERSION=="2010e"', {
                   'VCCLCompilerTool': {
                     'AdditionalOptions': [
                       '-fmsc-version=1600',
                     ],
                   },
                 }],
               ],
             }],
+            ['clang==1 and asan==1', {
+              # Building with Clang on Windows is a work in progress and very
+              # experimental. See crbug.com/82385.
+              'VCCLCompilerTool': {
+                'AdditionalOptions': [
+                  '-fsanitize=address',
+                ],
+              },
+              'target_conditions': [
+                ['_type=="executable"', {
+                  'VCLinkerTool': {
+                    'AdditionalOptions': [
+                       '<(make_clang_dir)/lib/clang/3.5/lib/windows/clang_rt.asan-i386.lib',
+                    ],
+                  },
+                }],
+                ['_type=="shared_library" or _type=="loadable_module"', {
+                  'VCLinkerTool': {
+                    'AdditionalOptions': [
+                       '<(make_clang_dir)/lib/clang/3.5/lib/windows/clang_rt.asan_dll_thunk-i386.lib',
+                    ],
+                  },
+                }],
+              ],
+            }],
           ],
         },
       },
     }],
     ['disable_nacl==1', {
       'target_defaults': {
         'defines': [
           'DISABLE_NACL',
         ],
       },
@@ skipping 170 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',
   },
 }