Revert "[Tracing] Use Perfetto client library for tracing on Linux"

This reverts commit d9e2da27d146aedf4cd8fb1dfd75b593fd346e53.

Reason for revert: causes flaky failures on Linux TSAN bot:
https://ci.chromium.org/p/chromium/builders/ci/Linux%20TSan%20Tests
https://screenshot.googleplex.com/7h3cqjcPav7q9m8 of current and previous state

Also causes linux-headless-shell-rel bot to fail, see here:
https://ci.chromium.org/ui/p/chromium/builders/ci/linux-headless-shell-rel/52404/overview

example Linux TSAN failures are here:
https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20TSan%20Tests/81148/overview
and here:
https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20TSan%20Tests/81149/overview

[ RUN      ] All/EmergencyStopTracingTest.StopOnThreadPoolTwice/1
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=31673)
  Cycle in lock order graph: M0 (0x7b4400010190) => M1 (0x7b1800051010) => M0
...

[ RUN      ] All/StartupTracingTest.TestEnableTracing/3
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=11003)
  Cycle in lock order graph: M0 (0x7b1800042bb0) => M1 (0x7b440001a190) => M0

[ RUN      ] All/StartupTracingTest.TestEnableTracing/8
WARNING: ThreadSanitizer: data race (pid=15510)
  Read of size 8 at 0x55aa9918d3a0 by thread T3:

These failures basically started with this landed.

Original change's description:
> [Tracing] Use Perfetto client library for tracing on Linux
>
> This CL switches the Chrome tracing backend to Perfetto client
> library. It means that Chrome on Linux will use a different set of
> TRACE_EVENT* macros that call Perfetto client API under the hood.
>
> Our end goal is to make Perfetto the default backend on all platforms,
> unblocking multiple improvements in tracing stability and usefulness.
> The Linux change is a first step towards that goal.
>
> Bug: 1006541
> Change-Id: I85f27a2e4b91f219e9fb4f90a391f4b5df90baa3
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4147340
> Reviewed-by: Andrew Grieve <agrieve@chromium.org>
> Commit-Queue: Mikhail Khokhlov <khokhlov@google.com>
> Reviewed-by: Eric Seckler <eseckler@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1090340}

Bug: 1006541
Change-Id: I3e4959aedb28f81dbcd8dda7141329e5e5e3fa1d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4148448
Owners-Override: Mark Pearson <mpearson@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Mark Pearson <mpearson@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1090431}
NOKEYCHECK=True
GitOrigin-RevId: b24cc3a7a4ca1ba15eb92aa3ec0bedb077663197
1 file changed
tree: 910e2e8bed10e23ad5d46bdaf2d4179cac04c2fc
  1. angle.gni
  2. build.gni
  3. dawn.gni
  4. glslang.gni
  5. gtest.gni
  6. ipcz.gni
  7. OWNERS
  8. partition_alloc.gni
  9. pdfium.gni
  10. README.md
  11. spirv_tools.gni
  12. swiftshader.gni
  13. tint.gni
  14. vulkan_common.gni
  15. vulkan_headers.gni
  16. vulkan_loader.gni
  17. vulkan_tools.gni
  18. vulkan_validation_layers.gni
  19. wayland.gni
README.md

Build overrides in GN

This directory is used to allow different products to customize settings for repos that are DEPS'ed in or shared.

For example: V8 could be built on its own (in a “standalone” configuration), and it could be built as part of Chromium. V8 might define a top-level target, //v8:d8 (a simple executable), that should only be built in the standalone configuration. To figure out whether or not it should be in a standalone configuration, v8 can create a file, build_overrides/v8.gni, that contains a variable, build_standalone_d8 = true. and import it (as import(“//build_overrides/v8.gni”) from its top-level BUILD.gn file.

Chromium, on the other hand, might not need to build d8, and so it would create its own build_overrides/v8.gni file, and in it set build_standalone_d8 = false.

The two files should define the same set of variables, but the values can vary as appropriate to the needs of the two different builds.

The build.gni file provides a way for projects to override defaults for variables used in //build itself (which we want to be shareable between projects).

TODO(crbug.com/588513): Ideally //build_overrides and, in particular, //build_overrides/build.gni should go away completely in favor of some mechanism that can re-use other required files like //.gn, so that we don't have to keep requiring projects to create a bunch of different files to use GN.