Revert of Cleaner fall-back stack capture for --enable-heap-profiling=native.

Revert of Cleaner fall-back stack capture for --enable-heap-profiling=native. (patchset #4 id:80001 of https://codereview.chromium.org/2757123002/ )

Reason for revert:
Broke Chrome for Android official builds (see crbug.com/706698), due to new dependency on debugging_flags.h header.

Original issue's description:
> Cleaner fall-back stack capture for --enable-heap-profiling=native.
> 
> This generalizes the fall-back to using base::debug::StackTrace to
> capture stack traces in builds which lack frame pointers, allowing
> native heap profiling to generate useful data, albeit with a more
> significant performance penalty.
> 
> Changes made in the earlier patch for native heap profiling stack
> capture under Windows are un-done in favour of the following:
> 1. MemoryDumpManager always allows native heap profiling[1].
> 2. HeapProfilerAllocationContextTracker chooses whether to use
>    base::debug::StackTrace or TraceStackFramePointers() based on
>    the value of HAVE_TRACE_STACK_FRAME_POINTERS().
> 3. HAVE_STACK_FRAME_POINTERS is no longer defined in configurations
>    which lack frame pointers[2].
> 
> [1] Though note that only certain build configs actually support
>     the necessary allocator shims; this will be addressed later.
> [2] Frame pointers are typically only available in enable_profiling
>     or Debug builds.
> 
> BUG=686208
> 
> Review-Url: https://codereview.chromium.org/2757123002
> Cr-Commit-Position: refs/heads/master@{#460311}
> Committed: https://chromium.googlesource.com/chromium/src/+/22b017b9b241c47db8cf25c57c89c0b0d7fcfbe2

TBR=dskiba@chromium.org,primiano@chromium.org,dcheng@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=686208
Review-Url: https://codereview.chromium.org/2790443002
Cr-Commit-Position: refs/heads/master@{#460679}
Committed: https://chromium.googlesource.com/chromium/src/+/3731f7d26c0d826826453efc211d7902bc61e3d9

[Wez, 2017-03-30 06:21:48]

The CQ bit was checked by wez@chromium.org

[Wez, 2017-03-30 06:21:49]

Created Revert of Cleaner fall-back stack capture for
--enable-heap-profiling=native.

[commit-bot: I haz the power, 2017-03-30 06:22:10]

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-03-30 06:22:58]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1490854908765970, "parent_rev":
"18514e66cea2de4f902f300d6b136f4bb9b18b6b", "commit_rev":
"3731f7d26c0d826826453efc211d7902bc61e3d9"}

[commit-bot: I haz the power, 2017-03-30 06:24:06]

Description was changed from

==========
Revert of Cleaner fall-back stack capture for --enable-heap-profiling=native.
(patchset #4 id:80001 of https://codereview.chromium.org/2757123002/ )

Reason for revert:
Broke Chrome for Android official builds (see crbug.com/706698), due to new
dependency on debugging_flags.h header.

Original issue's description:
> Cleaner fall-back stack capture for --enable-heap-profiling=native.
> 
> This generalizes the fall-back to using base::debug::StackTrace to
> capture stack traces in builds which lack frame pointers, allowing
> native heap profiling to generate useful data, albeit with a more
> significant performance penalty.
> 
> Changes made in the earlier patch for native heap profiling stack
> capture under Windows are un-done in favour of the following:
> 1. MemoryDumpManager always allows native heap profiling[1].
> 2. HeapProfilerAllocationContextTracker chooses whether to use
>    base::debug::StackTrace or TraceStackFramePointers() based on
>    the value of HAVE_TRACE_STACK_FRAME_POINTERS().
> 3. HAVE_STACK_FRAME_POINTERS is no longer defined in configurations
>    which lack frame pointers[2].
> 
> [1] Though note that only certain build configs actually support
>     the necessary allocator shims; this will be addressed later.
> [2] Frame pointers are typically only available in enable_profiling
>     or Debug builds.
> 
> BUG=686208
> 
> Review-Url: https://codereview.chromium.org/2757123002
> Cr-Commit-Position: refs/heads/master@{#460311}
> Committed:
https://chromium.googlesource.com/chromium/src/+/22b017b9b241c47db8cf25c57c89...

TBR=dskiba@chromium.org,primiano@chromium.org,dcheng@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=686208
==========

to

==========
Revert of Cleaner fall-back stack capture for --enable-heap-profiling=native.
(patchset #4 id:80001 of https://codereview.chromium.org/2757123002/ )

Reason for revert:
Broke Chrome for Android official builds (see crbug.com/706698), due to new
dependency on debugging_flags.h header.

Original issue's description:
> Cleaner fall-back stack capture for --enable-heap-profiling=native.
> 
> This generalizes the fall-back to using base::debug::StackTrace to
> capture stack traces in builds which lack frame pointers, allowing
> native heap profiling to generate useful data, albeit with a more
> significant performance penalty.
> 
> Changes made in the earlier patch for native heap profiling stack
> capture under Windows are un-done in favour of the following:
> 1. MemoryDumpManager always allows native heap profiling[1].
> 2. HeapProfilerAllocationContextTracker chooses whether to use
>    base::debug::StackTrace or TraceStackFramePointers() based on
>    the value of HAVE_TRACE_STACK_FRAME_POINTERS().
> 3. HAVE_STACK_FRAME_POINTERS is no longer defined in configurations
>    which lack frame pointers[2].
> 
> [1] Though note that only certain build configs actually support
>     the necessary allocator shims; this will be addressed later.
> [2] Frame pointers are typically only available in enable_profiling
>     or Debug builds.
> 
> BUG=686208
> 
> Review-Url: https://codereview.chromium.org/2757123002
> Cr-Commit-Position: refs/heads/master@{#460311}
> Committed:
https://chromium.googlesource.com/chromium/src/+/22b017b9b241c47db8cf25c57c89...

TBR=dskiba@chromium.org,primiano@chromium.org,dcheng@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=686208

Review-Url: https://codereview.chromium.org/2790443002
Cr-Commit-Position: refs/heads/master@{#460679}
Committed:
https://chromium.googlesource.com/chromium/src/+/3731f7d26c0d826826453efc211d...
==========

[commit-bot: I haz the power, 2017-03-30 06:24:07]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/3731f7d26c0d826826453efc211d...

[Primiano Tucci (use gerrit), 2017-03-30 11:52:22]

On 2017/03/30 06:24:07, commit-bot: I haz the power wrote:
> Committed patchset #1 (id:1) as
>
https://chromium.googlesource.com/chromium/src/+/3731f7d26c0d826826453efc211d...

Blast from the past, I've seen this revert for this reason before :)

I guess you missed dskiba's comment in crrev.com/2757123002 (the original CL)
about not include  #include "base/debug/debugging_flags.h" in the header,
because, quoting
dskiba@
---
Another thing is that last time I tried to use BUILDFLAG(ENABLE_PROFILING) in a
base/ header, I ended up in misery, because debugging_flags.h is generated when
base/ is built, but there is nothing preventing ninja from starting building
both foo/ (which depend on base/) and base/ at the same time. If something in
foo/ includes stack_trace.h and depends on HAVE_STACK_FRAME_POINTERS we end up
with non-deterministic build.
---

[Wez, 2017-03-31 05:44:21]

On 2017/03/30 11:52:22, Primiano Tucci wrote:
> On 2017/03/30 06:24:07, commit-bot: I haz the power wrote:
> > Committed patchset #1 (id:1) as
> >
>
https://chromium.googlesource.com/chromium/src/+/3731f7d26c0d826826453efc211d...
> 
> Blast from the past, I've seen this revert for this reason before :)
> 
> I guess you missed dskiba's comment in crrev.com/2757123002 (the original CL)
> about not include  #include "base/debug/debugging_flags.h" in the header,
> because, quoting
> dskiba@
> ---
> Another thing is that last time I tried to use BUILDFLAG(ENABLE_PROFILING) in
a
> base/ header, I ended up in misery, because debugging_flags.h is generated
when
> base/ is built, but there is nothing preventing ninja from starting building
> both foo/ (which depend on base/) and base/ at the same time. If something in
> foo/ includes stack_trace.h and depends on HAVE_STACK_FRAME_POINTERS we end up
> with non-deterministic build.
> ---

Yes, I noticed that comment, but it didn't make a lot of sense to me, since we
have other situations in which we have public headers include generated headers,
and that is apparently OK - e.g. see
https://cs.chromium.org/chromium/src/content/public/common/BUILD.gn?type=cs&q....
 Both cases involve a public_deps on a step that generates a header.

I think the problem is that mojom(...) templates generate a source_set() which
has the generated files as its |sources|, and then depends on the generator.  So
the buildflag_header(...) should be fixable to do the same thing.
Is there something different in the build-flags rule vs the mojom rule that
causes the dependency not to work, or is there something else I'm missing here?