Demangling symbols from bcc/bpf does not work

[jonhoo]

The ustack function from bpftrace/bcc produces symbols that for some reason cannot be parsed by rustc-demangle, such as:

_ZN100_$LT$tokio_tower..multiplex..server..Server$LT$T$C$S$GT$$u20$as$u20$core..future..future..Future$GT$4poll17hedb49c127bbef1efE+89

To test this yourself, run a Rust program and then bpftrace with something like:

sudo env BPFTRACE_NO_CPP_DEMANGLE=1 bpftrace -e 'profile:hz:1 /pid == '$(pgrep target/debug)'/ { printf("%ld %d %s\n", elapsed, tid, ustack) }'

And look at the resulting symbols. I suspect this is related to the .. characters, but as far as I can tell bcc just reads symbol names from /proc/kallsyms.

[jonhoo]

Some more symbols:

_ZN98_$LT$futures_util..future..either..Either$LT$A$C$B$GT$$u20$as$u20$core..future..future..Future$GT$4poll17h0645d1ee0292e6cfE+120
_ZN53_$LT$S$u20$as$u20$futures_core..stream..TryStream$GT$13try_poll_next17hdcf2fec9b9f35d76E+432
_ZN5tokio4task4core13Core$LT$T$GT$4poll17h7deeca20231cedd5E+87
_ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h8176c5ec09afcf4eE+310

Notably not all of them contain .., so maybe that's not the issue?

[alexcrichton]

Thanks for the report! I think it's due to the +NN at the end which doesn't typically show up with symbols. Do you know where that's coming from?

[jonhoo]

Ah, yes, it looks like you're right. Removing them causes the parsing to work correctly. The +NN syntax at the end is commonly used in all sorts of debugging/profiling contexts to mean "NN bytes past this symbol" (e.g., to highlight that a particular line of a function was sampled a lot). It might be a good idea to support symbols with that kind of suffix.