Implement Symbol Demanglers for Linux Binaries

[brianrob]

Implements C++ and Rust v0 demangling APIs. These were largely generated by Copilot, though I have lightly reviewed them. Extensive testing:

• Basic testing against the specs.
• 100% successful demangling of all symbols in libcoreclr.so (from .NET 10).
• 100% successful demangling of all symbols from 500 randomly selected Ubuntu dbg packages.
• 100% successful demangling of all symbols from 500 randomly selected Rust crates from crates.io.

Performance validation:

• Created and ran benchmarks using BenchmarkDotNet.
• Selected optimizations based on findings to improve CPU and memory efficiency.

Contributes to #2382.

[brianrob]

cc: @zachcmadsen

[leculver]

I have a few questions/suggestions before marking approve:

Allocations: I do wonder how much we are allocating when demangling. There are several places where we could be using ReadOnlySpan back and forth instead of creating new strings. There seems to be quite a few substring calls, and similar. Ultimately though, you have to build a new string for the demangled name, and I'm not sure how much time/GC we'd save by trying to do less allocations.

You are using Benchmark.Net, can you check how much the DemangleAll tests allocate, and subtract the result of _allSymbols.Sum(r => demangler.Demangle(symbol).Length)? If it's a really high number, maybe consider having copilot rewrite some of these demangle methods to not allocate? (Mostly be using read only spans in helpers.)

If the number seems reasonable, then don't bother, of course.

AllSymbols Demangle Test: Would we catch regressions better by demangling all symbols in cpp_symbols.txt/rust_symbols.txt and comparing it against a pre-demangled version? IE run everything through the demangler now, store that result and assert it in one final "check-all" test. This does nothing for us now, but if you have to modify the demangler in the future, it will ensure we don't actually drift old functions. (Or that any drift is good and actually fixing real bugs.)

Or does the tests as the exist now fully cover the entirety of demangling, and this would just be overhead?

[brianrob]

Thank you for the review @leculver.

Regarding allocations - I did a bunch of optimization in the allocation space before originally creating the PR. I had originally looked at potentially using ReadOnlySpan, but it turns out that the bulk of the allocation is in materializing the strings for the demangled symbol and not in reading/parsing the mangled name. That said, I did send copilot off to push further on this using the benchmarks, and it made some improvements using pooled StringBuilder instances, since that's where the bulk of the allocation happens. Here's the before/after findings:

DemangleAll — Full Corpus

The DemangleAll benchmarks demangle every symbol in the test corpus and are the most
representative measure of real-world impact.

Demangler	Runtime	Alloc Before	Alloc After	Alloc Reduction	Mean Before	Mean After	Speedup
Itanium	.NET 8.0	93.8 MB	54.9 MB	41%	43.0 ms	35.0 ms	19%
Itanium	.NET Framework 4.6.2	100.7 MB	58.2 MB	42%	73.7 ms	64.6 ms	12%
Itanium + Metadata	.NET 8.0	110.5 MB	61.1 MB	45%	57.6 ms	47.2 ms	18%
Itanium + Metadata	.NET Framework 4.6.2	118.4 MB	64.7 MB	45%	91.5 ms	80.4 ms	12%
Rust	.NET 8.0	34.7 MB	24.0 MB	31%	17.5 ms	15.6 ms	11%
Rust	.NET Framework 4.6.2	34.1 MB	25.5 MB	25%	27.5 ms	25.8 ms	6%

Per-Symbol Benchmarks — .NET 8.0

These benchmarks demangle a single symbol and show the allocation impact at different
symbol complexity levels.

Demangler	Symbol	Alloc Before	Alloc After	Alloc Reduction	Mean Before	Mean After
Itanium	Short	288 B	72 B	75%	83 ns	72 ns
Itanium	Medium	1,048 B	472 B	55%	471 ns	342 ns
Itanium	Long	1,799 KB	926 KB	49%	303 μs	238 μs
Itanium + Metadata	Short	352 B	88 B	75%	137 ns	114 ns
Itanium + Metadata	Medium	904 B	488 B	46%	357 ns	269 ns
Itanium + Metadata	Long	1,799 KB	926 KB	49%	302 μs	239 μs
Rust	Short	120 B	120 B	0%	86 ns	86 ns
Rust	Medium	1,400 B	1,088 B	22%	642 ns	592 ns
Rust	Long	227 KB	121 KB	47%	54 μs	43 μs

Regarding the tests - The txt files are just input to the benchmarks and not to any correctness tests. My goal was to have enough variation of mangling to get a reasonable read on performance, rather than just hitting the simple or complex cases. From a correctness perspective, the existing test cases are reasonably good, but I asked copilot to do a comparison between what we have in the functional test space and what exists in the allsymbols benchmark, and so it identified another 42 test cases to add.

All of these changes should now be pushed in separate commits so that you can see them without looking at the entire change.