Always try to demangle #28
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Can you share the source code for your test program and your exact compiler invocation that you use to compile it? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #24
If frame is not inline at adress_space line 385 and resolve_symbol returns None we won't try to demangle the symbol.
This moves the demangle code so it always tries to demangled the symbol from name.
May not be the best way to do this so feel free to close!
Tests pass, and the resulting flamegraph is cleaner.
For reference here's how I've capture and generate the flamegraph:
./nperf record -F 997 -p 1234 -o datafile
./nperf flamegraph datafile -d /usr/lib/debug/ > flame.svg
Also the symbols are available at the correct path on /usr/lib/debug, so I'm not sure exactly why resolve_symbols would fail ?
nm /usr/lib/debug/tmp/mybin | wc -l
37587
But looks like, it reported it loaded only 69 symbols?
[2022-08-31T17:18:03Z DEBUG nperf_core::data_reader] New binary: "/tmp/mybin"
[2022-08-31T17:18:03Z DEBUG nwind::debug_info_index] Requested debug info for '/tmp/mybin'; debuglink = Some("mybin"), build_id = None
[2022-08-31T17:18:03Z DEBUG nwind::debug_info_index] Debug info lookup result: bin = Some("/usr/lib/debug/tmp/mybin"), dbg = None
[2022-08-31T17:18:03Z DEBUG nwind::symbols] Loaded 69 symbols for '/tmp/mybin' (0 normal, 69 dynamic) in 0ms
Curious to see why build_id is none there as well, as the file does have a build-id
file /tmp/mybin
/tmp/mybin: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /tmp/.elf, for GNU/Linux 3.2.0, BuildID[sha1]=f5ba86caa2c7a6c8efed8efa44869bd268e740ec, stripped