C# mangling affects troubleshooting

[verdie-g]

This issue probably applies to other things than perf but it's what I mainly use.

When using perf on a .NET process, you'll get such symbols

class [System.Runtime]System.Threading.Tasks.Task`1<int32> [Test] Program::AsyncVoidMethodChild1(valuetype [System.Runtime]System.ValueTuple`2<int32,class [System.Collections]System.Collections.Generic.List`1<string>>)[MinOptJitted]

Spotting the method name (AsyncVoidMethodChild1 here) can be challenging which doesn't help analysis the perf result.

I've tried building the regex to parse a symbol but it's very challenging because it seems like there a lot of inconsistencies.

Would it possible to somehow have cleaned .NET symbols? For example above that would give

System.Threading.Tasks.Task<int32> Program.AsyncVoidMethodChild1((int32, System.Collections.Generic.List<string>))

Or alternatively, have a consistence mangling so it can be parsed.

What do I mean by inconsistent? Here are some examples:

void [Test] DummyWork::Consume(!!0&)[MinOptJitted]

What's !!0 ?

instance void [Criteo.KeyValueStore] Criteo.KeyValueStore.Storage.BucketStorage+<Sdk-Interfaces-KeyValueStore-IAsyncStorage-GetAsync>d__16::MoveNext()[OptimizedTier1]

why is - used

instance bool [System.Private.CoreLib] System.Collections.Generic.List`1+Enumerator[System.__Canon]::MoveNext()[OptimizedTier1]

Generic for the parent is '1 and doesn't specify the types, generic for the child class doesn't use '1 but brackets and what is System.__Canon.

[teo-tsirpanis]

Have you tried https://github.com/benaadams/Ben.Demystifier ?

[tannergooding]

It's worth noting that this isn't done by C# and isn't necessarily "mangling" per say.

This is rather the IL names as represented in metadata. !!0 and + is simply the symbols used to represent type parameters by index and nested types.

Since .NET is language agnostic and supports many languages (C#, F#, VB, C++/CLI, etc) it can't necessarily express these in terms of C#, particularly since some concepts are not expressible in C#.

There are some places where the language does emit "unspeakable" names (identifiers which can't be represented in C#), but those are typically for internal implementation details on how something may actually work behind the scenes (such as fixed sized buffers or a type used to hold captured variables for a lambda expression). Since such names are typically not part of the "public surface area", they may not have a strictly well-defined format and may change over time