[ANN] perf demangling of OCaml symbols (& a short introduction to perf)

[copy]

@gasche

(It looks like the patchset has not received comments yet. Is it something that we can/should help with?)

You could contribute by testing or reviewing the code and responding on the mailing list with a Tested-by or Reviewed-by tag. I’m not sure how much weight is given to first-time reviewers, but it certainly wouldn’t harm. See Submitting patches: the essential guide to getting your code into the kernel — The Linux Kernel documentation

@gasche

There are no string-size check before the sym[caml_prefix_len] access in ocaml_is_mangled , so with the input “caml” we are reading the terminating null byte here. This is safe and correct, but I found it a bit surprising. (Maybe this sentinel-like usage is familiar to kernel programmers, or just people who actually write C code for a living.)

The existing Rust demangler makes similar assumption, so I opted to write the OCaml demangler in the same style. I’m not sure about the strncmp case, but sym[i] == '_' && sym[i + 1] == '_' is certainly common in C codebases I’ve worked on.

@gasche

The final part of the demangling removes the _[0-9]* suffix of the symbol, that corresponds to a unique symbol identifier generated by the OCaml compiler backend.

@jjb

I haven’t had time to investigate yet, but I am also unsure about removing the integer suffixes. I often look at code in perf where there are multiple functions that have the same name up to the suffix due to (cross-module) inlining. For the utility of these low-level tools, I think that it is necessary for the demangling to preserve uniqueness of names.

This is a good point. I was under the impression that such cases were mostly unambiguous, but it seems to be more common than I thought. I’ll post a v2 of the patch on the mailing list that preserves the trailing identifier id.

@gasche

But I wonder if there are still some cases where we could want the information, which might suggest demangling camlMod__loop_2245 into, say, Mod.loop(2245) rather than just Mod.loop as the current patch does.

I’m not sure about the (2245) pattern, rather than just leaving _2245 in place. It makes it harder to correlate with cmm or disassembly output, e.g. when using grep. It also breaks the property that the demangled symbol is strictly smaller than the mangled symbol (or makes it harder to verify this property).

@vlaviron

(Because of this, a number of people use the double underscore in module names to trick the programmers and tools into believing that one module is actually a submodule of an other one (the most common example is dune’s wrapped libraries). I don’t consider this as mangling, as it’s not done by the compiler.)

Replacing __ by . is indeed a bit of a heuristic, but I think it results in more readable names in the end. Even in your example, the include Functor.F (M) line causes bar from functor.ml to be visible in the scope of the module Foo (and is later shadowed). Foo.bar is not a terrible name, especially in the presence (cross-module) inlining. An interesting questions is whether the compiler could generate symbol names in such situations, e.g. by appending [inlined from …], but unrelated to these changes.

To clarify, the patch currently modifies symbols generated by the OCaml compiler as follows:

1. Remove the caml prefix
2. Replace __ by .
3. Unescape $xx sequences, e.g. $2b → +
4. Remove trailing _\d+ (will be removed in the next version)