Reland of [tracing] Add native allocation tracing mode.

Reland of [tracing] Add native allocation tracing mode.

Original CL (1839503002) was reverted because it broke GYP builds. This CL
removes dependency on debugging_flags.h from a header and moves it into
a source file, avoiding the issue.

Original issue's description:
> [tracing] Add native allocation tracing mode.
>
> This change adds 'native' mode to '--enable-heap-profiling' option. When
> started with '--enable-heap-profiling=native' Chrome will keep native
> (real) stack traces for all live allocations. These native stack traces
> are then dumped to a trace file if 'memory-infra' category is enabled.
> Stack traces are dumped unsymbolized (for performance reasons), and there
> is a script (third_party/catapult/tracing/bin/symbolize_trace) that
> symbolizes all stack traces in a given trace file.
>
> Design document: https://goo.gl/DFoqfi
>
> Note: native stack tracing relies on frame pointers. You'll need to use
> either debug or a profiling release build (enable_profiling = true).
>
> Note: for now this all works on Linux @ x86/x64 only.

BUG=602701
TBR=mark@chromium.org

Committed: https://crrev.com/3de5ae3b200a3b86c9e7b48adbf2a4ed2c113216
Cr-Commit-Position: refs/heads/master@{#390449}

[Dmitry Skiba, 2016-04-26 07:35:56]

dskiba@google.com changed reviewers:
+ brettw@chromium.org, primiano@chromium.org

[Dmitry Skiba, 2016-04-26 07:40:04]

Description was changed from

==========
Reland of [tracing] Add native allocation tracing mode.

Original CL (1839503002) was reverted because it broke Windows build.
This CL includes a fix for that.

Original issue's description:
> [tracing] Add native allocation tracing mode.
>
> This change adds 'native' mode to '--enable-heap-profiling' option. When
> started with '--enable-heap-profiling=native' Chrome will keep native
> (real) stack traces for all live allocations. These native stack traces
> are then dumped to a trace file if 'memory-infra' category is enabled.
> Stack traces are dumped unsymbolized (for performance reasons), and there
> is a script (third_party/catapult/tracing/bin/symbolize_trace) that
> symbolizes all stack traces in a given trace file.
>
> Design document: https://goo.gl/DFoqfi
>
> Note: native stack tracing relies on frame pointers. You'll need to use
> either debug or a profiling release build (enable_profiling = true).
>
> Note: for now this all works on Linux @ x86/x64 only.
>

BUG=602701
==========

to

==========
Reland of [tracing] Add native allocation tracing mode.

Original CL (1839503002) was reverted because it broke GYP builds. This CL
includes a fix for that, which is to make sure that base target always builds
before any other target that depends on it.

Original issue's description:
> [tracing] Add native allocation tracing mode.
>
> This change adds 'native' mode to '--enable-heap-profiling' option. When
> started with '--enable-heap-profiling=native' Chrome will keep native
> (real) stack traces for all live allocations. These native stack traces
> are then dumped to a trace file if 'memory-infra' category is enabled.
> Stack traces are dumped unsymbolized (for performance reasons), and there
> is a script (third_party/catapult/tracing/bin/symbolize_trace) that
> symbolizes all stack traces in a given trace file.
>
> Design document: https://goo.gl/DFoqfi
>
> Note: native stack tracing relies on frame pointers. You'll need to use
> either debug or a profiling release build (enable_profiling = true).
>
> Note: for now this all works on Linux @ x86/x64 only.
>

BUG=602701
==========

[Primiano Tucci (use gerrit), 2016-04-26 15:20:14]

https://codereview.chromium.org/1921773003/diff/20001/base/base.gyp
File base/base.gyp (right):

https://codereview.chromium.org/1921773003/diff/20001/base/base.gyp#newcode16
base/base.gyp:16: 'hard_dependency': 1,
Hmm this is a strong hammer. Not sure we needed, neither not sure it will fly.

I think I know what's going on.
You are depending on BUILDFLAG(ENABLE_PROFILING) in
heap_profiler_allocation_context_tracker.h.
heap_profiler_allocation_context_tracker.h is a header, and can get included in
arbitrary targets before base's dependency (and in particular
base_debugging_flags which generates the header) are generated.
Here's my proposal: you don't really need that ENABLE_PROFILING everywhere, I
think you can be a bit less aggressive in ifdefing code out, as follows:

1) drop the #if ENABLE_NATIVE_ALLOCATION_TRACES in
heap_profiler_allocation_context_tracker.h, doesn't add a lot of value hiding an
enum value behind that flag.
2) drop the ifdef from heap_profiler_allocation_context_tracker.cc,
make the call to debug::TraceStackFramePointers depend on
HAVE_TRACE_STACK_FRAME_POINTERS and, DCHECK/NOTREACHED if you hit that case
without HAVE_TRACE_STACK_FRAME_POINTERS being defined.
3) The only place left where you need the buildflag is memory_dump_manager.cc.
Move all that ifdef logic inside the memory_dump_manager.cc file. 

Ta-daa, this will just work because memory_dump_manager.cc is a translation unit
which builds only inside of base, and base has a dependency on the buildflag
header.

[Primiano Tucci (use gerrit), 2016-04-26 16:03:23]

having said this, obviously if base owners are fine with this change I am fine
as well. it seems that there was some offline discussion before this change, I
mistakenly thought this was a hack created to make this work. 
in essence whateverzwhatever, if this should be reverted again at least now you
have a backup plan.

[Dmitry Skiba, 2016-04-26 16:03:26]

On 2016/04/26 15:20:14, Primiano Tucci wrote:
> https://codereview.chromium.org/1921773003/diff/20001/base/base.gyp
> File base/base.gyp (right):
> 
> https://codereview.chromium.org/1921773003/diff/20001/base/base.gyp#newcode16
> base/base.gyp:16: 'hard_dependency': 1,
> Hmm this is a strong hammer. Not sure we needed, neither not sure it will fly.
> 
> I think I know what's going on.
> You are depending on BUILDFLAG(ENABLE_PROFILING) in
> heap_profiler_allocation_context_tracker.h.
> heap_profiler_allocation_context_tracker.h is a header, and can get included
in
> arbitrary targets before base's dependency (and in particular
> base_debugging_flags which generates the header) are generated.
> Here's my proposal: you don't really need that ENABLE_PROFILING everywhere, I
> think you can be a bit less aggressive in ifdefing code out, as follows:
> 
> 1) drop the #if ENABLE_NATIVE_ALLOCATION_TRACES in
> heap_profiler_allocation_context_tracker.h, doesn't add a lot of value hiding
an
> enum value behind that flag.
> 2) drop the ifdef from heap_profiler_allocation_context_tracker.cc,
> make the call to debug::TraceStackFramePointers depend on
> HAVE_TRACE_STACK_FRAME_POINTERS and, DCHECK/NOTREACHED if you hit that case
> without HAVE_TRACE_STACK_FRAME_POINTERS being defined.
> 3) The only place left where you need the buildflag is memory_dump_manager.cc.
> Move all that ifdef logic inside the memory_dump_manager.cc file. 
> 
> Ta-daa, this will just work because memory_dump_manager.cc is a translation
unit
> which builds only inside of base, and base has a dependency on the buildflag
> header.

So here is a discussion I started about this in chromium-dev:
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/ykepYWpA5rg

Looks like Brett thinks that hard_dependency:1 might be OK solution for this.
Otherwise I'll implement what you've proposed (or a variation of that).

[Dmitry Skiba, 2016-04-26 17:12:33]

Brett, PTAL?

[Dmitry Skiba, 2016-04-27 04:23:51]

dskiba@google.com changed reviewers:
- brettw@chromium.org

[Dmitry Skiba, 2016-04-27 04:23:52]

PTAL, moved debugging_flags.h into .cc

[Dmitry Skiba, 2016-04-27 04:25:38]

Description was changed from

==========
Reland of [tracing] Add native allocation tracing mode.

Original CL (1839503002) was reverted because it broke GYP builds. This CL
includes a fix for that, which is to make sure that base target always builds
before any other target that depends on it.

Original issue's description:
> [tracing] Add native allocation tracing mode.
>
> This change adds 'native' mode to '--enable-heap-profiling' option. When
> started with '--enable-heap-profiling=native' Chrome will keep native
> (real) stack traces for all live allocations. These native stack traces
> are then dumped to a trace file if 'memory-infra' category is enabled.
> Stack traces are dumped unsymbolized (for performance reasons), and there
> is a script (third_party/catapult/tracing/bin/symbolize_trace) that
> symbolizes all stack traces in a given trace file.
>
> Design document: https://goo.gl/DFoqfi
>
> Note: native stack tracing relies on frame pointers. You'll need to use
> either debug or a profiling release build (enable_profiling = true).
>
> Note: for now this all works on Linux @ x86/x64 only.
>

BUG=602701
==========

to

==========
Reland of [tracing] Add native allocation tracing mode.

Original CL (1839503002) was reverted because it broke GYP builds. This CL
includes a fix for that, which is to make sure that base target always builds
before any other target that depends on it.

Original issue's description:
> [tracing] Add native allocation tracing mode.
>
> This change adds 'native' mode to '--enable-heap-profiling' option. When
> started with '--enable-heap-profiling=native' Chrome will keep native
> (real) stack traces for all live allocations. These native stack traces
> are then dumped to a trace file if 'memory-infra' category is enabled.
> Stack traces are dumped unsymbolized (for performance reasons), and there
> is a script (third_party/catapult/tracing/bin/symbolize_trace) that
> symbolizes all stack traces in a given trace file.
>
> Design document: https://goo.gl/DFoqfi
>
> Note: native stack tracing relies on frame pointers. You'll need to use
> either debug or a profiling release build (enable_profiling = true).
>
> Note: for now this all works on Linux @ x86/x64 only.

BUG=602701

TBR=mark@chromium.org
==========

[Primiano Tucci (use gerrit), 2016-04-27 12:43:26]

On 2016/04/27 04:23:52, Dmitry Skiba wrote:
> PTAL, moved debugging_flags.h into .cc
I think  you are making the situation more complicated than necessary:
Some of the code in heap_profiler_allocation_context_tracker.h is #ifdef-ed out
if !ENABLE_NATIVE_ALLOCATION_TRACES.
So when I read the code I ask to myself: what is this
ENABLE_NATIVE_ALLOCATION_TRACES? 
At first glance seems to be the compile-time variable that tells you whether we
can do native allocation tracking, but that is not true. in fact in
memory_dump_manager you reinforce it by adding (BUILDFLAG(ENABLE_PROFILING) ||
!defined(NDEBUG)).
In essence ENABLE_NATIVE_ALLOCATION_TRACES  is necessary but not sufficient.
As a summary, when reasoning about the heap profiler code now I have to keep
three variables in mind:
1. HAVE_TRACE_STACK_FRAME_POINTERS
2. ENABLE_NATIVE_ALLOCATION_TRACES 
3. ENABLE_NATIVE_ALLOCATION_TRACES +  (BUILDFLAG(ENABLE_PROFILING) ||
!defined(NDEBUG))

I think that all this complexity is unnecessary and makes the codebase harder to
read and reason about.
Specifically I don't understand what benefits 2. buys.

[Dmitry Skiba, 2016-04-27 15:35:14]

On 2016/04/27 12:43:26, Primiano Tucci wrote:
> On 2016/04/27 04:23:52, Dmitry Skiba wrote:
> > PTAL, moved debugging_flags.h into .cc
> I think  you are making the situation more complicated than necessary:
> Some of the code in heap_profiler_allocation_context_tracker.h is #ifdef-ed
out
> if !ENABLE_NATIVE_ALLOCATION_TRACES.
> So when I read the code I ask to myself: what is this
> ENABLE_NATIVE_ALLOCATION_TRACES? 
> At first glance seems to be the compile-time variable that tells you whether
we
> can do native allocation tracking, but that is not true. in fact in
> memory_dump_manager you reinforce it by adding (BUILDFLAG(ENABLE_PROFILING) ||
> !defined(NDEBUG)).
> In essence ENABLE_NATIVE_ALLOCATION_TRACES  is necessary but not sufficient.
> As a summary, when reasoning about the heap profiler code now I have to keep
> three variables in mind:
> 1. HAVE_TRACE_STACK_FRAME_POINTERS
> 2. ENABLE_NATIVE_ALLOCATION_TRACES 
> 3. ENABLE_NATIVE_ALLOCATION_TRACES +  (BUILDFLAG(ENABLE_PROFILING) ||
> !defined(NDEBUG))
> 
> I think that all this complexity is unnecessary and makes the codebase harder
to
> read and reason about.
> Specifically I don't understand what benefits 2. buys.

Hmm, yeah, I guess I can kill ENABLE_NATIVE_ALLOCATION_TRACES and replace it
with HAVE_TRACE_STACK_FRAME_POINTERS.

But I don't like situation where CaptureMode::NATIVE_STACK exists, but then
implementation calls NOTREACHED() in some cases, and logic to whether use
NATIVE_STACK or not is in some other .cc file.

So, let's kill ENABLE_NATIVE_ALLOCATION_TRACES and land this?

[Primiano Tucci (use gerrit), 2016-04-27 15:50:58]

On 2016/04/27 15:35:14, Dmitry Skiba wrote:
> Hmm, yeah, I guess I can kill ENABLE_NATIVE_ALLOCATION_TRACES and replace it
> with HAVE_TRACE_STACK_FRAME_POINTERS.
> But I don't like situation where CaptureMode::NATIVE_STACK exists, but then
> implementation calls NOTREACHED() in some cases, and logic to whether use
> NATIVE_STACK or not is in some other .cc file.

From a very practical viewpoint, I'm not a fan of having code #ifdeffed out
unless strictly necessary.
#ifdef code is harder to maintain. It means that if people refactor code around,
they can break the ifdef code because that is not covered.
I don't really care about the fact that the code is only used in some occasions,
I want it to be built and maintained.
Let's keep #ifdef sections as short as possible and only for the pieces of code
that we really need.
In this CL sounds like you really want only few lines in memory_dump_manager 
and StackFrame::FromProgramCounter to be #ifdeffed.
The rest of the code doesn't have any need.


> So, let's kill ENABLE_NATIVE_ALLOCATION_TRACES and land this?
Yup, and remove the unnecessary ifdefs

[Dmitry Skiba, 2016-04-27 16:57:07]

On 2016/04/27 15:50:58, Primiano Tucci wrote:
> On 2016/04/27 15:35:14, Dmitry Skiba wrote:
> > Hmm, yeah, I guess I can kill ENABLE_NATIVE_ALLOCATION_TRACES and replace it
> > with HAVE_TRACE_STACK_FRAME_POINTERS.
> > But I don't like situation where CaptureMode::NATIVE_STACK exists, but then
> > implementation calls NOTREACHED() in some cases, and logic to whether use
> > NATIVE_STACK or not is in some other .cc file.
> 
> From a very practical viewpoint, I'm not a fan of having code #ifdeffed out
> unless strictly necessary.
> #ifdef code is harder to maintain. It means that if people refactor code
around,
> they can break the ifdef code because that is not covered.
> I don't really care about the fact that the code is only used in some
occasions,
> I want it to be built and maintained.
> Let's keep #ifdef sections as short as possible and only for the pieces of
code
> that we really need.
> In this CL sounds like you really want only few lines in memory_dump_manager 
> and StackFrame::FromProgramCounter to be #ifdeffed.
> The rest of the code doesn't have any need.
> 
> 
> > So, let's kill ENABLE_NATIVE_ALLOCATION_TRACES and land this?
> Yup, and remove the unnecessary ifdefs

OK, see new version. I slightly reworked for() loop to get rid of ssize_t, which
is POSIX thing that probably doesn't exist on Windows. The change is simple -
'i' variable is now 1 off (and is always positive or 0), and we decrement in
inside the loop, just before using.

[Primiano Tucci (use gerrit), 2016-04-28 07:02:43]

LGTM w/ comments addressed.

https://codereview.chromium.org/1921773003/diff/60001/base/trace_event/heap_p...
File base/trace_event/heap_profiler_allocation_context_tracker.cc (right):

https://codereview.chromium.org/1921773003/diff/60001/base/trace_event/heap_p...
base/trace_event/heap_profiler_allocation_context_tracker.cc:151: for (const
auto& event_name: pseudo_stack_) {
minor thing: IMHO auto here adds little benefit, const char* instead of const
auto& would make this line more readable and less magical.

https://codereview.chromium.org/1921773003/diff/60001/base/trace_event/heap_p...
base/trace_event/heap_profiler_allocation_context_tracker.cc:165: const void*
frames[50];
I'd probably stay a bit more conservative and make this ~128 or so. Sometimes I
see scary frames when debugging. arrays on the stack are free of charge (as long
as you don't overflow the stack XD).

https://codereview.chromium.org/1921773003/diff/60001/base/trace_event/heap_p...
File base/trace_event/heap_profiler_allocation_context_tracker_unittest.cc
(right):

https://codereview.chromium.org/1921773003/diff/60001/base/trace_event/heap_p...
base/trace_event/heap_profiler_allocation_context_tracker_unittest.cc:1: //
Copyright 2015 The Chromium Authors. All rights reserved.
Would be nice to cover the code above (and the various corner cases) in this
unittest.
Let's do that in a separate CL after this sticks.
A good approach would be mocking at the base::debug::TraceStackFramePointers
level, by adding a mock_unwind_function_for_tests_ field.

https://codereview.chromium.org/1921773003/diff/60001/base/trace_event/memory...
File base/trace_event/memory_dump_manager.cc (right):

https://codereview.chromium.org/1921773003/diff/60001/base/trace_event/memory...
base/trace_event/memory_dump_manager.cc:15: #include "base/memory/ptr_util.h"
add an include to base/debug/stack_trace.h as that is what defines
HAVE_TRACE_STACK_FRAME_POINTERS.
I think here you are relying in some of this header pulling that, which is
fragile (and against IWYU)

[Primiano Tucci (use gerrit), 2016-04-28 07:09:49]

Ah also please fix the commit message, which does not reflect the change in the
reland anymore.

[Dmitry Skiba, 2016-04-28 15:45:01]

Description was changed from

==========
Reland of [tracing] Add native allocation tracing mode.

Original CL (1839503002) was reverted because it broke GYP builds. This CL
includes a fix for that, which is to make sure that base target always builds
before any other target that depends on it.

Original issue's description:
> [tracing] Add native allocation tracing mode.
>
> This change adds 'native' mode to '--enable-heap-profiling' option. When
> started with '--enable-heap-profiling=native' Chrome will keep native
> (real) stack traces for all live allocations. These native stack traces
> are then dumped to a trace file if 'memory-infra' category is enabled.
> Stack traces are dumped unsymbolized (for performance reasons), and there
> is a script (third_party/catapult/tracing/bin/symbolize_trace) that
> symbolizes all stack traces in a given trace file.
>
> Design document: https://goo.gl/DFoqfi
>
> Note: native stack tracing relies on frame pointers. You'll need to use
> either debug or a profiling release build (enable_profiling = true).
>
> Note: for now this all works on Linux @ x86/x64 only.

BUG=602701

TBR=mark@chromium.org
==========

to

==========
Reland of [tracing] Add native allocation tracing mode.

Original CL (1839503002) was reverted because it broke GYP builds. This CL
removes dependency on debugging_flags.h from a header and moves it into
a source file, avoiding the issue.

Original issue's description:
> [tracing] Add native allocation tracing mode.
>
> This change adds 'native' mode to '--enable-heap-profiling' option. When
> started with '--enable-heap-profiling=native' Chrome will keep native
> (real) stack traces for all live allocations. These native stack traces
> are then dumped to a trace file if 'memory-infra' category is enabled.
> Stack traces are dumped unsymbolized (for performance reasons), and there
> is a script (third_party/catapult/tracing/bin/symbolize_trace) that
> symbolizes all stack traces in a given trace file.
>
> Design document: https://goo.gl/DFoqfi
>
> Note: native stack tracing relies on frame pointers. You'll need to use
> either debug or a profiling release build (enable_profiling = true).
>
> Note: for now this all works on Linux @ x86/x64 only.

BUG=602701

TBR=mark@chromium.org
==========

[Dmitry Skiba, 2016-04-28 18:16:34]

https://codereview.chromium.org/1921773003/diff/60001/base/trace_event/heap_p...
File base/trace_event/heap_profiler_allocation_context_tracker.cc (right):

https://codereview.chromium.org/1921773003/diff/60001/base/trace_event/heap_p...
base/trace_event/heap_profiler_allocation_context_tracker.cc:151: for (const
auto& event_name: pseudo_stack_) {
On 2016/04/28 07:02:42, Primiano Tucci (traveling) wrote:
> minor thing: IMHO auto here adds little benefit, const char* instead of const
> auto& would make this line more readable and less magical.

Done.

https://codereview.chromium.org/1921773003/diff/60001/base/trace_event/heap_p...
base/trace_event/heap_profiler_allocation_context_tracker.cc:165: const void*
frames[50];
On 2016/04/28 07:02:42, Primiano Tucci (traveling) wrote:
> I'd probably stay a bit more conservative and make this ~128 or so. Sometimes
I
> see scary frames when debugging. arrays on the stack are free of charge (as
long
> as you don't overflow the stack XD).

Done.

https://codereview.chromium.org/1921773003/diff/60001/base/trace_event/memory...
File base/trace_event/memory_dump_manager.cc (right):

https://codereview.chromium.org/1921773003/diff/60001/base/trace_event/memory...
base/trace_event/memory_dump_manager.cc:15: #include "base/memory/ptr_util.h"
On 2016/04/28 07:02:42, Primiano Tucci (traveling) wrote:
> add an include to base/debug/stack_trace.h as that is what defines
> HAVE_TRACE_STACK_FRAME_POINTERS.
> I think here you are relying in some of this header pulling that, which is
> fragile (and against IWYU)

Done.

[Dmitry Skiba, 2016-04-28 19:33:36]

The CQ bit was checked by dskiba@google.com

[Dmitry Skiba, 2016-04-28 19:33:37]

The patchset sent to the CQ was uploaded after l-g-t-m from
primiano@chromium.org
Link to the patchset: https://codereview.chromium.org/1921773003/#ps80001
(title: "Address comments")

[commit-bot: I haz the power, 2016-04-28 19:34:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1921773003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1921773003/80001

[commit-bot: I haz the power, 2016-04-28 19:40:42]

Description was changed from

==========
Reland of [tracing] Add native allocation tracing mode.

Original CL (1839503002) was reverted because it broke GYP builds. This CL
removes dependency on debugging_flags.h from a header and moves it into
a source file, avoiding the issue.

Original issue's description:
> [tracing] Add native allocation tracing mode.
>
> This change adds 'native' mode to '--enable-heap-profiling' option. When
> started with '--enable-heap-profiling=native' Chrome will keep native
> (real) stack traces for all live allocations. These native stack traces
> are then dumped to a trace file if 'memory-infra' category is enabled.
> Stack traces are dumped unsymbolized (for performance reasons), and there
> is a script (third_party/catapult/tracing/bin/symbolize_trace) that
> symbolizes all stack traces in a given trace file.
>
> Design document: https://goo.gl/DFoqfi
>
> Note: native stack tracing relies on frame pointers. You'll need to use
> either debug or a profiling release build (enable_profiling = true).
>
> Note: for now this all works on Linux @ x86/x64 only.

BUG=602701

TBR=mark@chromium.org
==========

to

==========
Reland of [tracing] Add native allocation tracing mode.

Original CL (1839503002) was reverted because it broke GYP builds. This CL
removes dependency on debugging_flags.h from a header and moves it into
a source file, avoiding the issue.

Original issue's description:
> [tracing] Add native allocation tracing mode.
>
> This change adds 'native' mode to '--enable-heap-profiling' option. When
> started with '--enable-heap-profiling=native' Chrome will keep native
> (real) stack traces for all live allocations. These native stack traces
> are then dumped to a trace file if 'memory-infra' category is enabled.
> Stack traces are dumped unsymbolized (for performance reasons), and there
> is a script (third_party/catapult/tracing/bin/symbolize_trace) that
> symbolizes all stack traces in a given trace file.
>
> Design document: https://goo.gl/DFoqfi
>
> Note: native stack tracing relies on frame pointers. You'll need to use
> either debug or a profiling release build (enable_profiling = true).
>
> Note: for now this all works on Linux @ x86/x64 only.

BUG=602701

TBR=mark@chromium.org
==========

[commit-bot: I haz the power, 2016-04-28 19:40:45]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-04-30 17:20:19]

Patchset 5 (id:??) landed as
https://crrev.com/3de5ae3b200a3b86c9e7b48adbf2a4ed2c113216
Cr-Commit-Position: refs/heads/master@{#390449}

[commit-bot: I haz the power, 2016-04-30 17:56:58]

Description was changed from

==========
Reland of [tracing] Add native allocation tracing mode.

Original CL (1839503002) was reverted because it broke GYP builds. This CL
removes dependency on debugging_flags.h from a header and moves it into
a source file, avoiding the issue.

Original issue's description:
> [tracing] Add native allocation tracing mode.
>
> This change adds 'native' mode to '--enable-heap-profiling' option. When
> started with '--enable-heap-profiling=native' Chrome will keep native
> (real) stack traces for all live allocations. These native stack traces
> are then dumped to a trace file if 'memory-infra' category is enabled.
> Stack traces are dumped unsymbolized (for performance reasons), and there
> is a script (third_party/catapult/tracing/bin/symbolize_trace) that
> symbolizes all stack traces in a given trace file.
>
> Design document: https://goo.gl/DFoqfi
>
> Note: native stack tracing relies on frame pointers. You'll need to use
> either debug or a profiling release build (enable_profiling = true).
>
> Note: for now this all works on Linux @ x86/x64 only.

BUG=602701

TBR=mark@chromium.org
==========

to

==========
Reland of [tracing] Add native allocation tracing mode.

Original CL (1839503002) was reverted because it broke GYP builds. This CL
removes dependency on debugging_flags.h from a header and moves it into
a source file, avoiding the issue.

Original issue's description:
> [tracing] Add native allocation tracing mode.
>
> This change adds 'native' mode to '--enable-heap-profiling' option. When
> started with '--enable-heap-profiling=native' Chrome will keep native
> (real) stack traces for all live allocations. These native stack traces
> are then dumped to a trace file if 'memory-infra' category is enabled.
> Stack traces are dumped unsymbolized (for performance reasons), and there
> is a script (third_party/catapult/tracing/bin/symbolize_trace) that
> symbolizes all stack traces in a given trace file.
>
> Design document: https://goo.gl/DFoqfi
>
> Note: native stack tracing relies on frame pointers. You'll need to use
> either debug or a profiling release build (enable_profiling = true).
>
> Note: for now this all works on Linux @ x86/x64 only.

BUG=602701

TBR=mark@chromium.org

Committed: https://crrev.com/3de5ae3b200a3b86c9e7b48adbf2a4ed2c113216
Cr-Commit-Position: refs/heads/master@{#390449}
==========