Add experiments info to crash dumps.

chrome/chrome_tests.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.
 {
   'variables' : {
     'pyautolib_sources': [
       'app/chrome_command_ids.h',
       'app/chrome_dll_resource.h',
       'common/automation_constants.h',
       'common/pref_names.cc',
@@ skipping 2497 matching lines @@
           # RendererWebKitPlatformSupportImpl, which subclasses stuff in
           # glue, which refers to symbols defined in these files.
           # Hopefully this can be resolved with http://crbug.com/98755.
           'sources': [
             '../content/common/socket_stream_dispatcher.cc',
           ]},
         ],
       ],
     },
     {
+      'target_name': 'chrome_app_unittests',
+      'type': 'executable',
+      'dependencies': [
+        # unit tests should only depend on
+        # 1) everything that the chrome binaries depend on:
+        '<@(chromium_dependencies)',
+        # 2) test-specific support libraries:
+        '../testing/gmock.gyp:gmock',
+        '../testing/gtest.gyp:gtest',
+        'test_support_common',
+        # 3) anything tests directly depend on
+        '../breakpad/breakpad.gyp:*',
+      ],
+      'include_dirs': [
+        '..',
+      ],
+      'sources': [
+        'app/breakpad_win.cc',
+        'app/breakpad_win_unittest.cc',
+        'app/hard_error_handler_win.cc',
+        'app/run_all_unittests.cc'
+      ],
+      'conditions': [
+        ['OS=="mac"', {
+          # TODO(mark): We really want this for all non-static library targets,
+          # but when we tried to pull it up to the common.gypi level, it broke
+          # other things like the ui, startup, and page_cycler tests. *shrug*
+          'xcode_settings': {'OTHER_LDFLAGS': ['-Wl,-ObjC']},
+
+          # libwebcore.a is so large that ld may not have a sufficiently large
+          # "hole" in its address space into which it can be mmaped by the
+          # time it reaches this library. As of May 10, 2010, libwebcore.a is
+          # about 1GB in some builds. In the Mac OS X 10.5 toolchain, using
+          # Xcode 3.1, ld is only a 32-bit executable, and address space
+          # exhaustion is the result, with ld failing and producing
+          # the message:
+          # ld: in .../libwebcore.a, can't map file, errno=12
+          #
+          # As a workaround, ensure that libwebcore.a appears to ld first when
+          # linking unit_tests. This allows the library to be mmapped when
+          # ld's address space is "wide open." Other libraries are small
+          # enough that they'll be able to "squeeze" into the remaining holes.
+          # The Mac linker isn't so sensitive that moving this library to the
+          # front of the list will cause problems.
+          #
+          # Enough pluses to make get this target prepended to the target's
+          # list of dependencies.
+          'dependencies+++': [
+            '../third_party/WebKit/Source/WebCore/WebCore.gyp/WebCore.gyp:webcore',
+          ],
+        }],
+        ['OS=="win"', {
+          'conditions': [
+            ['win_use_allocator_shim==1', {

[robertshield, 2012/03/14 13:51:48]

is this needed for a test executable?

[MAD, 2012/03/15 22:37:36]

Dunno... I just copied that from other tests above... Should I remove it?

[robertshield, 2012/03/20 19:24:31]

Nah, on further investigation, it might be needed. Please ignore my previous
comment :)

+              'dependencies': [
+                '<(allocator_target)',
+              ],
+            }],
+          ],
+          'configurations': {
+            'Debug_Base': {
+              'msvs_settings': {
+                'VCLinkerTool': {
+                  # Forcing incremental build off to try to avoid incremental
+                  # linking errors on 64-bit bots too. http://crbug.com/52555
+                  'LinkIncremental': '1',
+                },
+              },
+            },
+          },
+        }, { # else: OS != "win"
+          'sources!': [
+            'app/breakpad_win.cc',

[robertshield, 2012/03/14 13:51:48]

I think source files ending in _win.cc are already only built on Windows via
magical gyp magicky-ness.

[MAD, 2012/03/15 22:37:36]

Again, I followed what I saw in other projects... I'll give it a try... Thanks

+            'app/breakpad_win_unittest.cc',

[robertshield, 2012/03/14 13:51:48]

I don't know if the same is true of win_unittest.cc, if it isn't you may want to
rename that file to breakpad_unittest_win.cc.

[MAD, 2012/03/15 22:37:36]

OK, I'll try that too... Thanks!
Although the pattern _win_unittest is much more common than _unittest_win...
Historical?

[robertshield, 2012/03/20 19:24:31]

Could be :-) Turns out that win_unittest is handled as well as per
src\build\filename_rules.gypi.

+            'app/hard_error_handler_win.cc',
+          ],
+        }],
+      ],
+    },
+    {
       # Executable that runs each browser test in a new process.
       'target_name': 'browser_tests',
       'type': 'executable',
       'msvs_cygwin_shell': 0,
       'msvs_cygwin_dirs': ['<(DEPTH)/third_party/cygwin'],
       'dependencies': [
         'browser',
         'browser/sync/protocol/sync_proto.gyp:sync_proto',
         'chrome',
         'chrome_resources.gyp:chrome_resources',
@@ skipping 2186 matching lines @@
               # Use outputs of this action as inputs for the main target build.
               # Seems as a misnomer but makes this happy on Linux (scons).
               'process_outputs_as_sources': 1,
             },
           ],  # 'actions'
         },
       ]
     }],  # 'coverage!=0'
   ],  # 'conditions'
 }