Fix ASLR Windows build configuration

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 965 matching lines @@
       'win_debug_InlineFunctionExpansion%': '',    # empty = default, 0 = off,
       'win_release_InlineFunctionExpansion%': '2', # 1 = only __inline, 2 = max
 
       # VS inserts quite a lot of extra checks to algorithms like
       # std::partial_sort in Debug build which make them O(N^2)
       # instead of O(N*logN). This is particularly slow under memory
       # tools like ThreadSanitizer so we want it to be disablable.
       # See http://msdn.microsoft.com/en-us/library/aa985982(v=VS.80).aspx
       'win_debug_disable_iterator_debugging%': '0',
 
+      # Tri-state: blank is VS default, 1 on, 0 off
+      'win_release_RandomizedBaseAddress%': '1',

[Sigurður Ásgeirsson, 2012/01/10 20:18:34]

You set this to a stringified-one '1' here, but the test is against a numeric
one.

[Derek Bruening, 2012/01/10 20:48:53]

Right, I will change this to numeric.

[M-A Ruel, 2012/01/10 21:02:00]

I must say I'm unhappy about that, that's why I filed http://crbug.com/109780.

Why not just create a new configuration for Dr Memory instead? All these
settings shouldn't be settings, I want to do the exact reverse. :/

+      # Tri-state: blank is VS default, 1 on, 0 off.  Off by default: see below.
+      'win_debug_RandomizedBaseAddress%': '0',
+
       'release_extra_cflags%': '',
       'debug_extra_cflags%': '',
       'release_valgrind_build%': 0,
 
       # the non-qualified versions are widely assumed to be *nix-only
       'win_release_extra_cflags%': '',
       'win_debug_extra_cflags%': '',
 
       # TODO(thakis): Make this a blacklist instead, http://crbug.com/101600
       'enable_wexit_time_destructors%': '<(enable_wexit_time_destructors)',
@@ skipping 514 matching lines @@
                 # perform FPO regardless, so we must explicitly disable.
                 # We still want the false setting above to avoid having
                 # "/Oy /Oy-" and warnings about overriding.
                 'AdditionalOptions': ['/Oy-'],
               }],
             ],
             'AdditionalOptions': [ '<@(win_debug_extra_cflags)', ],
           },
           'VCLinkerTool': {
             'LinkIncremental': '<(msvs_debug_link_incremental)',
-            # ASLR makes debugging with windbg difficult because Chrome.exe and
-            # Chrome.dll share the same base name. As result, windbg will
-            # name the Chrome.dll module like chrome_<base address>, where
-            # <base address> typically changes with each launch. This in turn
-            # means that breakpoints in Chrome.dll don't stick from one launch
-            # to the next. For this reason, we turn ASLR off in debug builds.
-            # Note that this is a three-way bool, where 0 means to pick up
-            # the default setting, 1 is off and 2 is on.
-            'RandomizedBaseAddress': 1,
+            'conditions': [
+              # ASLR makes debugging with windbg difficult because Chrome.exe
+              # and Chrome.dll share the same base name. As result, windbg will
+              # name the Chrome.dll module like chrome_<base address>, where
+              # <base address> typically changes with each launch. This in turn
+              # means that breakpoints in Chrome.dll don't stick from one launch
+              # to the next. For this reason, we turn ASLR off in debug builds.
+              # Note that this is a three-way bool, where 0 means to pick up
+              # the default setting, 1 is off and 2 is on.
+              # Also note that an explicit /dynamicbase linker flag will
+              # override this setting.
+
+              # If win_debug_RandomizedBaseAddress is blank, leave as default
+              # (that's VS default: off for VS2008, on for VS2010).
+              ['win_debug_RandomizedBaseAddress==1', {

[Sigurður Ásgeirsson, 2012/01/10 20:18:34]

did you intend 'win_debug_RandomizedBaseAddress=="1"', or should the default
value assignment above perhaps be numeric?

[Derek Bruening, 2012/01/10 20:48:53]

Above should be numeric.

+                'RandomizedBaseAddress': 2,
+              }],
+              ['win_debug_RandomizedBaseAddress==0', {
+                'RandomizedBaseAddress': 1,
+              }],
+            ],
           },
           'VCResourceCompilerTool': {
             'PreprocessorDefinitions': ['_DEBUG'],
           },
         },
         'conditions': [
           ['OS=="linux"', {
             'cflags': [
               '<@(debug_extra_cflags)',
             ],
@@ skipping 58 matching lines @@
             # LinkIncremental is a tri-state boolean, where 0 means default
             # (i.e., inherit from parent solution), 1 means false, and
             # 2 means true.
             'LinkIncremental': '1',
             # This corresponds to the /PROFILE flag which ensures the PDB
             # file contains FIXUP information (growing the PDB file by about
             # 5%) but does not otherwise alter the output binary. This
             # information is used by the Syzygy optimization tool when
             # decomposing the release image.
             'Profile': 'true',
+            'conditions': [
+              # If win_release_RandomizedBaseAddress is blank, leave as default.
+              # For RandomizedBaseAddress: 0=default, 1=off, 2=on
+              ['win_release_RandomizedBaseAddress==1', {
+                'RandomizedBaseAddress': 2,
+              }],
+              ['win_release_RandomizedBaseAddress==0', {
+                'RandomizedBaseAddress': 1,
+              }],
+            ],
           },
         },
         'conditions': [
           ['release_valgrind_build==0', {
             'defines': [
               'NVALGRIND',
               'DYNAMIC_ANNOTATIONS_ENABLED=0',
             ],
           }, {
             'defines': [
@@ skipping 1121 matching lines @@
               'uxtheme.dll',
             ],
           },
         },
         'configurations': {
           'x86_Base': {
             'msvs_settings': {
               'VCLinkerTool': {
                 'AdditionalOptions': [
                   '/safeseh',
-                  '/dynamicbase',
                   '/ignore:4199',
                   '/ignore:4221',
                   '/nxcompat',
                 ],
               },
             },
           },
           'x64_Base': {
             'msvs_settings': {
               'VCLinkerTool': {
                 'AdditionalOptions': [
                   # safeseh is not compatible with x64
-                  '/dynamicbase',
                   '/ignore:4199',
                   '/ignore:4221',
                   '/nxcompat',
                 ],
               },
             },
           },
         },
       },
     }],
@@ skipping 34 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',
   },
 }