Rust support in Linux `perf` tool


As my first contribution to Linux I added support for showing readable Rust symbols in Linux’s perf performance counter profiling tool. If you are doing performance-related work in Rust on Linux you want this patch.

For some examples of what perf is useful for, here is perf showing relative amount of time spent in individual functions:

And at the machine instruction level, inline with the source code:

Here are the steps for cloning and building perf with my patch. Note that the build requires about 500 MB of disk space.

git init perf-core
cd perf-core/
git remote add tip git://
git config core.sparsecheckout true
cat > .git/info/sparse-checkout << SPARSE
git pull --depth=1 tip perf/core
cd tools/perf/
CC=gcc make

The make command will tell you which development headers you need to install. Just keep trying until you get it right. I had to install binutils-dev, libaudit-dev, libdw-dev, libelf-dev, libgtk2.0-dev, libiberty-dev, liblzma-dev, libnuma-dev, libperl-dev, libslang2-dev, libunwind8-dev. There may have been others that I already had installed.


Thank you for doing that! I think my brain had just gotten used to reading the mangled form too. :slight_smile:



We just recently tweaked the stdlib’s demangler to add a couple more cases that it looks like the kernel patch missed: Might be worth pushing upstream?


Nice, hopefully it gets integrated by cargo-profiler soon.

Callgrind and cachegrind have been usable for a while now.


This is so awesome!


In response to some reddit comments:


This is awesome, but I’m not thrilled about the de facto stabilization of our symbol mangling, which was mostly hacked in to prevent LLVM from complaining.


I’m not sure I like this… In principle, it’s great that perf gets Rust support. But our current symbol mangling scheme is historically grown without much of a long-term plan behind it, afaik.

The patch as written will not do The Wrong Thing. In the worst case it will do nothing - showing you what you would have seen without the patch. I guess consider it a preview of how nice it will be when things are stabilized.


@dtolnay: Sorry for sounding a bit negative there. It really is great that we have support for the current encoding! Especially since it will still be around for a while.


This is available in the new 4.8 release of Linux.


Do you know if it ever was or if there’s a a github issue for it?