[WIP] Add more mangling information to demangling API.

[AdamBrouwersHarries]

Overview: This patch adds a field to FrameDebugInfo to store the (original) mangled name that has been retrieved during symbolication, and extends demangle_any to return the demangling scheme used, as well as the demangled name. This allows users of the demangle_any interface and FrameDebugInfo to access (respectively) the scheme by which a given name was mangled, as well as the original mangled name.

Rationale: I'm currently working on a tool that needs to be able to symbolicise in precisely the same way that samply-symbols/wholesym provides, with one cavaet: I need to be able to access the original mangled names.

Given an address (e.g. from a firefox profile), this is currently quite difficult, as there is no "built-in" way to retrieve an address. Users would instead have to retrieve a de-mangled name from a symbolication source and then manually mangle it themselves. Given the difficulties of mangling, combined with the various sources of mangling (e.g. finding a name from code compiled with MSVC, but re-mangling into an Itanium form), this approach is extremely difficult.

The specific case that I'm interested in is transforming processed Firefox profiles into Clang PGO (profile guided optimisation) compatible profiles. Clang's PGO optimisations are compatibile with sampling based profilers, but require mangled names.

[mstange]

Interesting, so this gives the mangled names both for the outer function and for any functions that were inlined at the sampled code addresses. Do you know what clang expects for inlined functions? Does it want to know if an inlined function call is hit, or is it ok to just tell it about the outer functions?

[fire]

Is there any reason this isn't merged other than time and effort to review etc.