[Reland] base: make CHECK macros trap at distinct addresses in official builds

[Reland] base: make CHECK macros trap at distinct addresses in official builds

Original CL: https://crrev.com/2502953003
Revert: https://crrev.com/2706453004
Reason for relanding:
masked out OS_NACL which was failing to build because of this error:
"GNU-style inline assembly is disabled"

Original CL Description:
> Abstract
> --------
> CHECK() is the macro used all over the places (~4K occurrences without
> counting for dupes due to inlining) for release-time assertions.
> It is enabled in a minimal form (crash without a message) in official builds.
> It needs to be fast as it is used in lot of fastpath.
> It needs to not emit too much code, as it is used in lot of places.
> It needs to guarantee that crash reports can pinpoint to the right
> location when hitting a CHECK.
>
> - Back in the days CHECK was fat, slow, but crash-friendly.
> - After crrev.com/1982123002 it became tiny, fast but not crash friendly.
> - This CL is making it a bit less tiny (+28/+128K), fast and crash friendly.
>
> The problem this CL deals with is the case of multiple CHECK()s within
> the same function. Also, adds a test that covers Mac, Linux and Android.
>
> A bit of history:
> -----------------
> Before crrev.com/1982123002 (reverted and later re-landed in
> crrev.com/2125923002) CHECK() in official builds was essentially:
> if (!condition) BreakDebugger()
> It was later found that this approach was not efficient, both in terms
> of binary size and performance. More importantly it was a regression
> w.r.t. blink's assert that were later switched to CHECK().
> "[blink-dev] Update of wtf/Assertions.h, and ASSERT macros deprecation"
> The major reason for this is DebuggerBreak being quite complex and
> not treated as noreturn by the compiler.
> It seems (see crbug.com/664209 for more) that the most efficient way to
> handle these checks is ending up with:
>
> Source code:
>   CHECK(cond1);
>   CHECK(cond2);
>   ...
>
> Ideal assembly:
> (ideal for perf and binary, but not for crash reports, more below)
>     compare_opcode  cond1;
>     jump_if_zero    prologue;
>     compare_opcode  cond2;
>     jump_if_zero    prologue;
>     ...
>  prologue:
>     trap_instruction(s)
>
> Rather than something like:
>     compare_opcode    cond1;
>     jump_if_NOT_zero  next1;
>     trap_instruction(s)
> next1:
>     compare_opcode    cond2;
>     jump_if_NOT_zero  next2;
>     trap_instruction(s)
> next2:
>     ...
> Where essentially the trap instructions are interleaved within the
> main execution flow. This is even worse if the trap instruction is
> actually a call to a function, with annex frame initialization,
> as in the case of BreakDebugger(). That bloats the binary and
> reduces i-cache hotness for the main flow.
>
> crrev.com/1982123002 recently fixed the situation making the
> assembly look like the ideal case above. Unfortunately this caused
> another problem due the extreme optimization: once the program
> crashes in "trap_instruction(s)", there is no easy way to tell which condition
> caused the trap. In practice this translates into the inability of
> tell which CHECK failed in a function that has more than one check.
>
> This CL:
> --------
> Re-addresses crrev.com/2125923002, adding an extra instruction after
> the trap which creates an opcode with a unique counter. This prevents
> the compiler from folding the trap instructions, still applying no-return
> optimizations.
> Also by doing this the various prologue get properly attributed to the
> CHECK line in debugging symbols.
>
> Binary size inflation on official builds:
> -----------------------------------------
> Android arm:    48684276  -> 48712948  = 28 K
> Android arm64:  85611800  -> 85665048  = 53 K
> Android x86_64:  91904944 -> 91933616 = 28 K
> Linux x86_64: 124219488 -> 124346464 = 124 K
> (Android build with -Os, hence why the difference between the two)
>

BUG=664209, 599867
TBR=mark@chromium.org

Review-Url: https://codereview.chromium.org/2705053002
Cr-Commit-Position: refs/heads/master@{#451749}
Committed: https://chromium.googlesource.com/chromium/src/+/f53167270c44da971a2f085299404319e42756f4

[Primiano Tucci (use gerrit), 2017-02-20 12:26:33]

The CQ bit was checked by primiano@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-20 12:26:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Primiano Tucci (use gerrit), 2017-02-20 12:28:45]

Description was changed from

==========
[Reland] base: make CHECK macros trap at distinct addresses in official builds

Original CL: https://crrev.com/2502953003
Revert: https://crrev.com/2706453004
Reason for relanding:
masked out OS_NACL which was failing to build because of this error:
"GNU-style inline assembly is disabled"

Original CL Description:
> Abstract
> --------
> CHECK() is the macro used all over the places (~4K occurrences without
> counting for dupes due to inlining) for release-time assertions.
> It is enabled in a minimal form (crash without a message) in official builds.
> It needs to be fast as it is used in lot of fastpath.
> It needs to not emit too much code, as it is used in lot of places.
> It needs to guarantee that crash reports can pinpoint to the right
> location when hitting a CHECK.
>
> - Back in the days CHECK was fat, slow, but crash-friendly.
> - After crrev.com/1982123002 it became tiny, fast but not crash friendly.
> - This CL is making it a bit less tiny (+28/+128K), fast and crash friendly.
>
> The problem this CL deals with is the case of multiple CHECK()s within
> the same function. Also, adds a test that covers Mac, Linux and Android.
>
> A bit of history:
> -----------------
> Before crrev.com/1982123002 (reverted and later re-landed in
> crrev.com/2125923002) CHECK() in official builds was essentially:
> if (!condition) BreakDebugger()
> It was later found that this approach was not efficient, both in terms
> of binary size and performance. More importantly it was a regression
> w.r.t. blink's assert that were later switched to CHECK().
> "[blink-dev] Update of wtf/Assertions.h, and ASSERT macros deprecation"
> The major reason for this is DebuggerBreak being quite complex and
> not treated as noreturn by the compiler.
> It seems (see crbug.com/664209 for more) that the most efficient way to
> handle these checks is ending up with:
>
> Source code:
>   CHECK(cond1);
>   CHECK(cond2);
>   ...
>
> Ideal assembly:
> (ideal for perf and binary, but not for crash reports, more below)
>     compare_opcode  cond1;
>     jump_if_zero    prologue;
>     compare_opcode  cond2;
>     jump_if_zero    prologue;
>     ...
>  prologue:
>     trap_instruction(s)
>
> Rather than something like:
>     compare_opcode    cond1;
>     jump_if_NOT_zero  next1;
>     trap_instruction(s)
> next1:
>     compare_opcode    cond2;
>     jump_if_NOT_zero  next2;
>     trap_instruction(s)
> next2:
>     ...
> Where essentially the trap instructions are interleaved within the
> main execution flow. This is even worse if the trap instruction is
> actually a call to a function, with annex frame initialization,
> as in the case of BreakDebugger(). That bloats the binary and
> reduces i-cache hotness for the main flow.
>
> crrev.com/1982123002 recently fixed the situation making the
> assembly look like the ideal case above. Unfortunately this caused
> another problem due the extreme optimization: once the program
> crashes in "trap_instruction(s)", there is no easy way to tell which condition
> caused the trap. In practice this translates into the inability of
> tell which CHECK failed in a function that has more than one check.
>
> This CL:
> --------
> Re-addresses crrev.com/2125923002, adding an extra instruction after
> the trap which creates an opcode with a unique counter. This prevents
> the compiler from folding the trap instructions, still applying no-return
> optimizations.
> Also by doing this the various prologue get properly attributed to the
> CHECK line in debugging symbols.
>
> Binary size inflation on official builds:
> -----------------------------------------
> Android arm:    48684276  -> 48712948  = 28 K
> Android arm64:  85611800  -> 85665048  = 53 K
> Android x86_64:  91904944 -> 91933616 = 28 K
> Linux x86_64: 124219488 -> 124346464 = 124 K
> (Android build with -Os, hence why the difference between the two)
>

BUG=664209,599867
==========

to

==========
[Reland] base: make CHECK macros trap at distinct addresses in official builds

Original CL: https://crrev.com/2502953003
Revert: https://crrev.com/2706453004
Reason for relanding:
masked out OS_NACL which was failing to build because of this error:
"GNU-style inline assembly is disabled"

Original CL Description:
> Abstract
> --------
> CHECK() is the macro used all over the places (~4K occurrences without
> counting for dupes due to inlining) for release-time assertions.
> It is enabled in a minimal form (crash without a message) in official builds.
> It needs to be fast as it is used in lot of fastpath.
> It needs to not emit too much code, as it is used in lot of places.
> It needs to guarantee that crash reports can pinpoint to the right
> location when hitting a CHECK.
>
> - Back in the days CHECK was fat, slow, but crash-friendly.
> - After crrev.com/1982123002 it became tiny, fast but not crash friendly.
> - This CL is making it a bit less tiny (+28/+128K), fast and crash friendly.
>
> The problem this CL deals with is the case of multiple CHECK()s within
> the same function. Also, adds a test that covers Mac, Linux and Android.
>
> A bit of history:
> -----------------
> Before crrev.com/1982123002 (reverted and later re-landed in
> crrev.com/2125923002) CHECK() in official builds was essentially:
> if (!condition) BreakDebugger()
> It was later found that this approach was not efficient, both in terms
> of binary size and performance. More importantly it was a regression
> w.r.t. blink's assert that were later switched to CHECK().
> "[blink-dev] Update of wtf/Assertions.h, and ASSERT macros deprecation"
> The major reason for this is DebuggerBreak being quite complex and
> not treated as noreturn by the compiler.
> It seems (see crbug.com/664209 for more) that the most efficient way to
> handle these checks is ending up with:
>
> Source code:
>   CHECK(cond1);
>   CHECK(cond2);
>   ...
>
> Ideal assembly:
> (ideal for perf and binary, but not for crash reports, more below)
>     compare_opcode  cond1;
>     jump_if_zero    prologue;
>     compare_opcode  cond2;
>     jump_if_zero    prologue;
>     ...
>  prologue:
>     trap_instruction(s)
>
> Rather than something like:
>     compare_opcode    cond1;
>     jump_if_NOT_zero  next1;
>     trap_instruction(s)
> next1:
>     compare_opcode    cond2;
>     jump_if_NOT_zero  next2;
>     trap_instruction(s)
> next2:
>     ...
> Where essentially the trap instructions are interleaved within the
> main execution flow. This is even worse if the trap instruction is
> actually a call to a function, with annex frame initialization,
> as in the case of BreakDebugger(). That bloats the binary and
> reduces i-cache hotness for the main flow.
>
> crrev.com/1982123002 recently fixed the situation making the
> assembly look like the ideal case above. Unfortunately this caused
> another problem due the extreme optimization: once the program
> crashes in "trap_instruction(s)", there is no easy way to tell which condition
> caused the trap. In practice this translates into the inability of
> tell which CHECK failed in a function that has more than one check.
>
> This CL:
> --------
> Re-addresses crrev.com/2125923002, adding an extra instruction after
> the trap which creates an opcode with a unique counter. This prevents
> the compiler from folding the trap instructions, still applying no-return
> optimizations.
> Also by doing this the various prologue get properly attributed to the
> CHECK line in debugging symbols.
>
> Binary size inflation on official builds:
> -----------------------------------------
> Android arm:    48684276  -> 48712948  = 28 K
> Android arm64:  85611800  -> 85665048  = 53 K
> Android x86_64:  91904944 -> 91933616 = 28 K
> Linux x86_64: 124219488 -> 124346464 = 124 K
> (Android build with -Os, hence why the difference between the two)
>

BUG=664209,599867
TBR=mark@chromium.org
==========

[Primiano Tucci (use gerrit), 2017-02-20 12:28:45]

primiano@chromium.org changed reviewers:
+ mark@chromium.org

[commit-bot: I haz the power, 2017-02-20 15:47:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-20 15:47:12]

Dry run: This issue passed the CQ dry run.

[Primiano Tucci (use gerrit), 2017-02-21 10:05:47]

The CQ bit was checked by primiano@chromium.org

[commit-bot: I haz the power, 2017-02-21 10:06:08]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-21 10:11:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-21 10:11:16]

Failed to apply patch for base/logging.h:
While running git apply --index -p1;
  error: patch failed: base/logging.h:496
  error: base/logging.h: patch does not apply

Patch:       base/logging.h
Index: base/logging.h
diff --git a/base/logging.h b/base/logging.h
index
6f30bcbe4f736f989bad178ac3d96ed70bf08943..0b135a7808af38ae52144066765f19948064459e
100644
--- a/base/logging.h
+++ b/base/logging.h
@@ -496,9 +496,60 @@ class CheckOpResult {
   std::string* message_;
 };
 
-// Crashes in the fastest, simplest possible way with no attempt at logging.
+// Crashes in the fastest possible way with no attempt at logging.
+// There are different constraints to satisfy here, see http://crbug.com/664209
+// for more context:
+// - The trap instructions, and hence the PC value at crash time, have to be
+//   distinct and not get folded into the same opcode by the compiler.
+//   On Linux/Android this is tricky because GCC still folds identical
+//   asm volatile blocks. The workaround is generating distinct opcodes for
+//   each CHECK using the __COUNTER__ macro.
+// - The debug info for the trap instruction has to be attributed to the source
+//   line that has the CHECK(), to make crash reports actionable. This rules
+//   out the ability of using a inline function, at least as long as clang
+//   doesn't support attribute(artificial).
+// - Failed CHECKs should produce a signal that is distinguishable from an
+//   invalid memory access, to improve the actionability of crash reports.
+// - The compiler should treat the CHECK as no-return instructions, so that the
+//   trap code can be efficiently packed in the prologue of the function and
+//   doesn't interfere with the main execution flow.
+// - When debugging, developers shouldn't be able to accidentally step over a
+//   CHECK. This is achieved by putting opcodes that will cause a non
+//   continuable exception after the actual trap instruction.
+// - Don't cause too much binary bloat.
 #if defined(COMPILER_GCC)
-#define IMMEDIATE_CRASH() __builtin_trap()
+
+#if defined(ARCH_CPU_X86_FAMILY) && !defined(OS_NACL)
+// int 3 will generate a SIGTRAP.
+#define TRAP_SEQUENCE() \
+  asm volatile(         \
+      "int3; ud2; push %0;" ::"i"(static_cast<unsigned char>(__COUNTER__)))
+
+#elif defined(ARCH_CPU_ARMEL) && !defined(OS_NACL)
+// bkpt will generate a SIGBUS when running on armv7 and a SIGTRAP when running
+// as a 32 bit userspace app on arm64. There doesn't seem to be any way to
+// cause a SIGTRAP from userspace without using a syscall (which would be a
+// problem for sandboxing).
+#define TRAP_SEQUENCE() \
+  asm volatile("bkpt #0; udf %0;" ::"i"(__COUNTER__ % 256))
+
+#elif defined(ARCH_CPU_ARM64) && !defined(OS_NACL)
+// This will always generate a SIGTRAP on arm64.
+#define TRAP_SEQUENCE() \
+  asm volatile("brk #0; hlt %0;" ::"i"(__COUNTER__ % 65536))
+
+#else
+// Crash report accuracy will not be guaranteed on other architectures, but at
+// least this will crash as expected.
+#define TRAP_SEQUENCE() __builtin_trap()
+#endif  // ARCH_CPU_*
+
+#define IMMEDIATE_CRASH()    \
+  ({                         \
+    TRAP_SEQUENCE();         \
+    __builtin_unreachable(); \
+  })
+
 #elif defined(COMPILER_MSVC)
 #define IMMEDIATE_CRASH() __debugbreak()
 #else

[Primiano Tucci (use gerrit), 2017-02-21 10:45:01]

The CQ bit was checked by primiano@chromium.org

[commit-bot: I haz the power, 2017-02-21 10:45:28]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Mark Mentovai, 2017-02-21 12:45:49]

LGTM

[commit-bot: I haz the power, 2017-02-21 13:09:30]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1487673901981730,
"parent_rev": "c96ea05e8b2961eb5d57829018fea8821b57acfd", "commit_rev":
"f53167270c44da971a2f085299404319e42756f4"}

[commit-bot: I haz the power, 2017-02-21 13:10:05]

Description was changed from

==========
[Reland] base: make CHECK macros trap at distinct addresses in official builds

Original CL: https://crrev.com/2502953003
Revert: https://crrev.com/2706453004
Reason for relanding:
masked out OS_NACL which was failing to build because of this error:
"GNU-style inline assembly is disabled"

Original CL Description:
> Abstract
> --------
> CHECK() is the macro used all over the places (~4K occurrences without
> counting for dupes due to inlining) for release-time assertions.
> It is enabled in a minimal form (crash without a message) in official builds.
> It needs to be fast as it is used in lot of fastpath.
> It needs to not emit too much code, as it is used in lot of places.
> It needs to guarantee that crash reports can pinpoint to the right
> location when hitting a CHECK.
>
> - Back in the days CHECK was fat, slow, but crash-friendly.
> - After crrev.com/1982123002 it became tiny, fast but not crash friendly.
> - This CL is making it a bit less tiny (+28/+128K), fast and crash friendly.
>
> The problem this CL deals with is the case of multiple CHECK()s within
> the same function. Also, adds a test that covers Mac, Linux and Android.
>
> A bit of history:
> -----------------
> Before crrev.com/1982123002 (reverted and later re-landed in
> crrev.com/2125923002) CHECK() in official builds was essentially:
> if (!condition) BreakDebugger()
> It was later found that this approach was not efficient, both in terms
> of binary size and performance. More importantly it was a regression
> w.r.t. blink's assert that were later switched to CHECK().
> "[blink-dev] Update of wtf/Assertions.h, and ASSERT macros deprecation"
> The major reason for this is DebuggerBreak being quite complex and
> not treated as noreturn by the compiler.
> It seems (see crbug.com/664209 for more) that the most efficient way to
> handle these checks is ending up with:
>
> Source code:
>   CHECK(cond1);
>   CHECK(cond2);
>   ...
>
> Ideal assembly:
> (ideal for perf and binary, but not for crash reports, more below)
>     compare_opcode  cond1;
>     jump_if_zero    prologue;
>     compare_opcode  cond2;
>     jump_if_zero    prologue;
>     ...
>  prologue:
>     trap_instruction(s)
>
> Rather than something like:
>     compare_opcode    cond1;
>     jump_if_NOT_zero  next1;
>     trap_instruction(s)
> next1:
>     compare_opcode    cond2;
>     jump_if_NOT_zero  next2;
>     trap_instruction(s)
> next2:
>     ...
> Where essentially the trap instructions are interleaved within the
> main execution flow. This is even worse if the trap instruction is
> actually a call to a function, with annex frame initialization,
> as in the case of BreakDebugger(). That bloats the binary and
> reduces i-cache hotness for the main flow.
>
> crrev.com/1982123002 recently fixed the situation making the
> assembly look like the ideal case above. Unfortunately this caused
> another problem due the extreme optimization: once the program
> crashes in "trap_instruction(s)", there is no easy way to tell which condition
> caused the trap. In practice this translates into the inability of
> tell which CHECK failed in a function that has more than one check.
>
> This CL:
> --------
> Re-addresses crrev.com/2125923002, adding an extra instruction after
> the trap which creates an opcode with a unique counter. This prevents
> the compiler from folding the trap instructions, still applying no-return
> optimizations.
> Also by doing this the various prologue get properly attributed to the
> CHECK line in debugging symbols.
>
> Binary size inflation on official builds:
> -----------------------------------------
> Android arm:    48684276  -> 48712948  = 28 K
> Android arm64:  85611800  -> 85665048  = 53 K
> Android x86_64:  91904944 -> 91933616 = 28 K
> Linux x86_64: 124219488 -> 124346464 = 124 K
> (Android build with -Os, hence why the difference between the two)
>

BUG=664209,599867
TBR=mark@chromium.org
==========

to

==========
[Reland] base: make CHECK macros trap at distinct addresses in official builds

Original CL: https://crrev.com/2502953003
Revert: https://crrev.com/2706453004
Reason for relanding:
masked out OS_NACL which was failing to build because of this error:
"GNU-style inline assembly is disabled"

Original CL Description:
> Abstract
> --------
> CHECK() is the macro used all over the places (~4K occurrences without
> counting for dupes due to inlining) for release-time assertions.
> It is enabled in a minimal form (crash without a message) in official builds.
> It needs to be fast as it is used in lot of fastpath.
> It needs to not emit too much code, as it is used in lot of places.
> It needs to guarantee that crash reports can pinpoint to the right
> location when hitting a CHECK.
>
> - Back in the days CHECK was fat, slow, but crash-friendly.
> - After crrev.com/1982123002 it became tiny, fast but not crash friendly.
> - This CL is making it a bit less tiny (+28/+128K), fast and crash friendly.
>
> The problem this CL deals with is the case of multiple CHECK()s within
> the same function. Also, adds a test that covers Mac, Linux and Android.
>
> A bit of history:
> -----------------
> Before crrev.com/1982123002 (reverted and later re-landed in
> crrev.com/2125923002) CHECK() in official builds was essentially:
> if (!condition) BreakDebugger()
> It was later found that this approach was not efficient, both in terms
> of binary size and performance. More importantly it was a regression
> w.r.t. blink's assert that were later switched to CHECK().
> "[blink-dev] Update of wtf/Assertions.h, and ASSERT macros deprecation"
> The major reason for this is DebuggerBreak being quite complex and
> not treated as noreturn by the compiler.
> It seems (see crbug.com/664209 for more) that the most efficient way to
> handle these checks is ending up with:
>
> Source code:
>   CHECK(cond1);
>   CHECK(cond2);
>   ...
>
> Ideal assembly:
> (ideal for perf and binary, but not for crash reports, more below)
>     compare_opcode  cond1;
>     jump_if_zero    prologue;
>     compare_opcode  cond2;
>     jump_if_zero    prologue;
>     ...
>  prologue:
>     trap_instruction(s)
>
> Rather than something like:
>     compare_opcode    cond1;
>     jump_if_NOT_zero  next1;
>     trap_instruction(s)
> next1:
>     compare_opcode    cond2;
>     jump_if_NOT_zero  next2;
>     trap_instruction(s)
> next2:
>     ...
> Where essentially the trap instructions are interleaved within the
> main execution flow. This is even worse if the trap instruction is
> actually a call to a function, with annex frame initialization,
> as in the case of BreakDebugger(). That bloats the binary and
> reduces i-cache hotness for the main flow.
>
> crrev.com/1982123002 recently fixed the situation making the
> assembly look like the ideal case above. Unfortunately this caused
> another problem due the extreme optimization: once the program
> crashes in "trap_instruction(s)", there is no easy way to tell which condition
> caused the trap. In practice this translates into the inability of
> tell which CHECK failed in a function that has more than one check.
>
> This CL:
> --------
> Re-addresses crrev.com/2125923002, adding an extra instruction after
> the trap which creates an opcode with a unique counter. This prevents
> the compiler from folding the trap instructions, still applying no-return
> optimizations.
> Also by doing this the various prologue get properly attributed to the
> CHECK line in debugging symbols.
>
> Binary size inflation on official builds:
> -----------------------------------------
> Android arm:    48684276  -> 48712948  = 28 K
> Android arm64:  85611800  -> 85665048  = 53 K
> Android x86_64:  91904944 -> 91933616 = 28 K
> Linux x86_64: 124219488 -> 124346464 = 124 K
> (Android build with -Os, hence why the difference between the two)
>

BUG=664209,599867
TBR=mark@chromium.org

Review-Url: https://codereview.chromium.org/2705053002
Cr-Commit-Position: refs/heads/master@{#451749}
Committed:
https://chromium.googlesource.com/chromium/src/+/f53167270c44da971a2f08529940...
==========

[commit-bot: I haz the power, 2017-02-21 13:10:05]

Committed patchset #3 (id:40001) as
https://chromium.googlesource.com/chromium/src/+/f53167270c44da971a2f08529940...

[Mark Mentovai, 2017-02-21 14:21:50]

https://codereview.chromium.org/2705053002/diff/40001/base/logging.h
File base/logging.h (right):

https://codereview.chromium.org/2705053002/diff/40001/base/logging.h#newcode565
base/logging.h:565: (__debugbreak(), (void)(*reinterpret_cast<volatile unsigned
char*>(0) = \
If Lexan supports GCC-style inline asm, we could use the above for this.

[Primiano Tucci (use gerrit), 2017-02-21 14:27:51]

https://codereview.chromium.org/2705053002/diff/40001/base/logging.h
File base/logging.h (right):

https://codereview.chromium.org/2705053002/diff/40001/base/logging.h#newcode565
base/logging.h:565: (__debugbreak(), (void)(*reinterpret_cast<volatile unsigned
char*>(0) = \
On 2017/02/21 14:21:50, Mark Mentovai wrote:
> If Lexan supports GCC-style inline asm, we could use the above for this.

Yup, realized the same too late. I just left a comment on Scott's CL in
https://codereview.chromium.org/2701253005/diff/1/base/logging.h#newcode515