commit e65c405aa1d63b9e8bfb07f317aee5cc3007af92
author Ryan Savitski <rsavitski@google.com> Thu Mar 24 18:22:19 2022 +0000
committer Ryan Savitski <rsavitski@google.com> Thu Mar 24 18:22:19 2022 +0000
tree 70539abd83d25b1d2964b2aa3f7e899a8aa53464
parent 6c4a33cc8d5b0640ce6c86413fa93b99aa7851b4

trace_processor: use llvm frame demangling in standalone builds

This changes the Demangle() SQL function offered by trace processor to,
depending on build config, demangle function names using a small subset
of sources pulled from llvm-project (as a buildtools dependency). The
benefits are: demangling is no longer dependent on the platform that
trace processor runs on, and support for non-Itanium mangling schemes
(notably, Rust's _R v0 mangling). By default, this is enabled in
standalone GN builds, and can be turned off using
gn/perfetto.gni. The fallback implementation is the
current cpp runtime function (abi::__cxa_demangle).

One odd thing that this changes for standalone builds: in debug builds,
the llvm sources require c++14 (which is the project's natural standard
level, so the release logic might require it as well in the future). So
we build them using -std=c++14, and link the results into the rest of
the build that is using -std=c++11. This relies on the compiler being
ABI compatible across the two standards, and we assume that's the case
for the compilers we target in standalone builds. For example, I've read
that for GCC keeping such configurations sane is an explicit goal.

All wiring for standalone Bazel build is done and works if you make
tools/gen_bazel set enable_perfetto_llvm_demangle=true. Planning to make
that the default soon, but it's simpler for the google-internal
embedding if we do that separately.

The Bazel wiring introduces two indirections in PERFETTO_CONFIG, to
allow for the entire demangling target to be swapped out if necessary.
This will be used in google-internal builds, but all other embedders are
expected to stick to the default implementation.

Side-change: the nop fallback implementation (if on Windows and not
using llvm demangling) now returns nullptr to indicate that demangling
always fails, which is more consistent with the codepaths that attempt
demangling. Previously it returned the input string.

Bug: 204297290
Change-Id: Ic7844d02cce1418f11869a4ed32a4c59f866a766