Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Demangling symbols from bcc/bpf does not work #34

Open
jonhoo opened this issue Jan 15, 2020 · 3 comments
Open

Demangling symbols from bcc/bpf does not work #34

jonhoo opened this issue Jan 15, 2020 · 3 comments

Comments

@jonhoo
Copy link

jonhoo commented Jan 15, 2020

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
Copy link
Author

jonhoo commented Jan 15, 2020

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
Copy link
Member

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
Copy link
Author

jonhoo commented Jan 16, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants