Enable frame pointers explicitly under ARM32.

build/config/compiler/compiler.gni

 # Copyright 2015 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.
 
 import("//build/config/android/config.gni")
 import("//build/config/arm.gni")
 import("//build/config/chrome_build.gni")
 import("//build/config/chromecast_build.gni")
 import("//build/config/compiler/pgo/pgo.gni")
 import("//build/config/sanitizers/sanitizers.gni")
@@ skipping 58 matching lines @@
 # Whether to emit frame pointers by default.
 if (is_mac || is_ios) {
   enabled_frame_pointers = true
 } else if (is_win) {
   # 64-bit Windows ABI doesn't support frame pointers.
   if (target_cpu == "x64") {
     enabled_frame_pointers = false
   } else {
     enabled_frame_pointers = true
   }
+} else if (current_cpu == "arm64") {
+  # Ensure that stacks from arm64 crash dumps are usable (crbug.com/391706).
+  enabled_frame_pointers = true;
+} else if (current_cpu == "arm") {
+  # TODO(711784): Building without frame pointers can lead to code which
+  # triggers some ARM A12/A17 errata.

[diandersAtChromium, 2017/04/19 17:35:25]

Do we think this really happens on Android versions of Chrome, too?  The old
condition allowed "no frame pointers" on arm on android.

[Wez, 2017/04/19 18:14:58]

That's a good question; I don't see any reason why Android vs CrOS would make a
difference for a given CPU architecture - if you are confident that this is
specific to the combination of Thumb+A12/A17+FPU/Neon then we can make the
condition more specific.

However, as per our conversation with gmx@, it sounds like even in the absence
of this issue we want frame pointers on ChromeOS to support CWP, so I think this
condition should become just os_chrome, in fact - we should be explicitly
enabling frame pointers for *all* ChromeOS builds, not just ARM32 - following
Erik's patch we've actually broken CWP on CrOS x86 & x64, IIUC.

+  enabled_frame_pointers = true;
 } else {
   # Explicitly ask for frame pointers, otherwise:
   # * Stacks may be missing for sanitizer and profiling builds.
   # * Debug tcmalloc can crash (crbug.com/636489).
-  # * Stacks may be missing for arm64 crash dumps (crbug.com/391706).
-  enabled_frame_pointers =
-      using_sanitizer || enable_profiling || is_debug || current_cpu == "arm64"
+  enabled_frame_pointers = using_sanitizer || enable_profiling || is_debug;
 }
 
 # Unwinding with frame pointers requires that they are enabled by default for
 # most translation units, that they are emitted correctly, and that the
 # compiler or platform provides a way to access them.
-if (current_cpu == "arm" && arm_use_thumb) {
-  # ARM Thumb builds do not emit frame pointers correctly.
+if (current_cpu == "arm") {
+  # We cannot currently unwind ARM32 frame pointers correctly.

[erikchen, 2017/04/19 02:43:57]

Technically, we can never unwind all stacks on any platform. See discussion in
first 10 comments on Issue 706654. The point of this variable is whether we can
unwind "most" stacks. This isn't very satisfactory...but is what we've been
doing for heap profiling.

I think this will break heap profiling on Chrome on Android. Can we add back the
&& arm_use_thumb condition? I don't think this should affect ChromeOS, only heap
profiling code.

[DmitrySkiba, 2017/04/19 15:06:09]

Yes, this will break Android heap profiler. We can unwind on ARM32, provided
that we're not in Thumb mode (this requires manual arm_use_thumb=false). Please
change the condition back.

As for uwnding "most" stacks - this depends on how malloc is hooked. On Android
we're wrapping malloc, i.e. intercepting malloc calls only made by the Chrome
itself. In this setup we can unwind all the stacks we need to unwind.

[Wez, 2017/04/19 18:14:58]

Oh, interesting: gmx@ stated that we can't unwind ARM32 stacks properly in
general, hence the change. I'll change it back.
Right; the reason we're special-casing ARM/Thumb is that even in the ideal case
(i.e. nothing in-between frames causing confusion) we can't unwind properly.

   can_unwind_with_frame_pointers = false
 } else if (is_win) {
   # Windows 32-bit does provide frame pointers, but the compiler does not
   # provide intrinsics to access them, so we don't use them.
   can_unwind_with_frame_pointers = false
 } else {
   can_unwind_with_frame_pointers = enabled_frame_pointers
 }
 
 declare_args() {
@@ skipping 58 matching lines @@
 }
 
 # Assert that the configuration isn't going to hit https://crbug.com/648948.
 assert(ignore_elf32_limitations || !is_android ||
            (android_64bit_target_cpu && !build_apk_secondary_abi) ||
            is_component_build || symbol_level < 2,
        "Android 32-bit non-component builds cannot have symbol_level=2 " +
            "due to 4GiB file size limit, see https://crbug.com/648948. " +
            "If you really want to try this out, " +
            "set ignore_elf32_limitations=true.")