Add basic tracing support to the gtest launcher

base/test/launcher/test_launcher_tracer.cc

Index: base/test/launcher/test_launcher_tracer.cc
diff --git a/base/test/launcher/test_launcher_tracer.cc b/base/test/launcher/test_launcher_tracer.cc
new file mode 100644
index 0000000000000000000000000000000000000000..238311666ea937a8b2b4102ae28af65ee8ed4783
--- /dev/null
+++ b/base/test/launcher/test_launcher_tracer.cc
@@ -0,0 +1,54 @@
+// Copyright 2016 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.
+
+#include "base/test/launcher/test_launcher_tracer.h"
+
+#include "base/json/json_file_value_serializer.h"
+#include "base/strings/stringprintf.h"
+#include "base/values.h"
+
+namespace base {
+
+TestLauncherTracer::TestLauncherTracer() : trace_start_time_(TimeTicks::Now()) {
+}
+
+TestLauncherTracer::~TestLauncherTracer() {
+}
+
+void TestLauncherTracer::RecordProcessExecution(
+    TimeTicks start_time, TimeDelta duration) {
+  AutoLock lock(lock_);
+
+  Event event;
+  event.name = StringPrintf("process #%zu", events_.size());
+  event.timestamp = start_time;
+  event.duration = duration;
+  event.thread_id = PlatformThread::CurrentId();

[Primiano Tucci (use gerrit), 2016/07/01 11:34:30]

Not sure you want this, as opposite as passing a hardcoded tid.
The practical difference is that, in the UI, each thread id shows as a separate
track. In other words the TID acts like a "namespace" for the events.
If you use this, all the events started from the same PID and TID will show on a
different track. But maybe this is what you want after all.

[Paweł Hajdan Jr., 2016/07/01 12:47:32]

Yup, that's actually what I want. When I didn't use TID, the result was often
unreadable. It looks good to me when TID is passed.

+  events_.push_back(event);

[Primiano Tucci (use gerrit), 2016/07/01 11:34:30]

It's not goting to make any major difference but technically you need to acquire
the lock only at this point to insert the event in the list, you don't really
need it before to construct the object.

[Paweł Hajdan Jr., 2016/07/01 12:47:32]

Well, events_ is read above to compute event name. I think it's fine as is.

+}
+
+bool TestLauncherTracer::Dump(const FilePath& path) {
+  AutoLock lock(lock_);
+
+  std::unique_ptr<ListValue> json_events(new ListValue);

[Primiano Tucci (use gerrit), 2016/07/01 11:34:30]

does this import in TraceViewer?
I thought you have to enclose the events in a "traceEvents" dictionary, as
follows:
{"traceEvents":[
  {pid: ..., tid;...},
  {pid: ..., tid;...},
]}

But maybe there is some legacy format that we still support that didn't require
the traceEvents container?

[Paweł Hajdan Jr., 2016/07/01 12:47:32]

Yeah, there's a format which takes just a list. It's mentioned in the doc you've
sent me.

+  for (const Event& event : events_) {
+    std::unique_ptr<DictionaryValue> json_event(new DictionaryValue);
+    json_event->SetString("name", event.name);
+    json_event->SetString("ph", "X");
+    json_event->SetInteger(
+        "ts", (event.timestamp - trace_start_time_).InMicroseconds());
+    json_event->SetInteger("dur", event.duration.InMicroseconds());
+    json_event->SetInteger("tid", event.thread_id);
+
+    // Add fake values required by the trace viewer.
+    json_event->SetInteger("pid", 0);
+
+    json_events->Append(std::move(json_event));
+  }
+
+  JSONFileValueSerializer serializer(path);
+  return serializer.Serialize(*json_events);
+}
+
+}  // namespace base