Support symbol demangling #50
Assignees
Labels
enhancement
New feature or request
Comments
|
I am positive about this feature. (opt-in) One related feature is to look up symbols demangled? I mean mapping from symbol names to addresses. And one function name may match more than one demangled symbol. Although this feature is kind of independent. |
I'd do this as integrated feature, because for C/C++ users of blazesym adding extra Rust library dependency might not be that convenient. This also seems like a very popular feature, so having an option to request this from blazesym directly seems like a good idea. |
danielocfb
added
help wanted
|
It may be a bit more work to get this done, at least to get it done properly. Will take care of it. The gist is that at least for DWARF, we probably don't want to just attempt the various demangling schemes but honor the LANG attribute, if available. In addition, last I checked we did not yet report fully qualified names there, so that will need to be fixed (e.g., only |
d-e-s-o
added a commit
to d-e-s-o/blazesym
that referenced
this issue
Jul 24, 2023
TODO: Need more tests for different languages. This change adds support for transparent demangling of symbols. Demangling is generally runtime configurable (via the previously added Builder flag), but because it involves additional dependencies there is also the option to disable it at compile time. If disabled at compile time, the runtime option becomes a no-op. Demangling currently happens in a single location inside the Symbolizer type. This has the advantage of concentrating the feature's implementation. However, it means that we need to bubble up the inferred language from all resolvers -- something that the recently added IntSym type helps us with. Closes: libbpf#50 Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
to d-e-s-o/blazesym
that referenced
this issue
Jul 24, 2023
TODO: Need more tests for different languages. This change adds support for transparent demangling of symbols. Demangling is generally runtime configurable (via the previously added Builder flag), but because it involves additional dependencies there is also the option to disable it at compile time. If disabled at compile time, the runtime option becomes a no-op. Demangling currently happens in a single location inside the Symbolizer type. This has the advantage of concentrating the feature's implementation. However, it means that we need to bubble up the inferred language from all resolvers -- something that the recently added IntSym type helps us with. Closes: libbpf#50 Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
to d-e-s-o/blazesym
that referenced
this issue
Jul 24, 2023
TODO: Need more tests for different languages. This change adds support for transparent demangling of symbols. Demangling is generally runtime configurable (via the previously added Builder flag), but because it involves additional dependencies there is also the option to disable it at compile time. If disabled at compile time, the runtime option becomes a no-op. Demangling currently happens in a single location inside the Symbolizer type. This has the advantage of concentrating the feature's implementation. However, it means that we need to bubble up the inferred language from all resolvers -- something that the recently added IntSym type helps us with. Closes: libbpf#50 Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
to d-e-s-o/blazesym
that referenced
this issue
Jul 24, 2023
TODO: Need more tests for different languages. This change adds support for transparent demangling of symbols. Demangling is generally runtime configurable (via the previously added Builder flag), but because it involves additional dependencies there is also the option to disable it at compile time. If disabled at compile time, the runtime option becomes a no-op. Demangling currently happens in a single location inside the Symbolizer type. This has the advantage of concentrating the feature's implementation. However, it means that we need to bubble up the inferred language from all resolvers -- something that the recently added IntSym type helps us with. Closes: libbpf#50 Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
to d-e-s-o/blazesym
that referenced
this issue
Jul 24, 2023
TODO: Need more tests for different languages. This change adds support for transparent demangling of symbols. Demangling is generally runtime configurable (via the previously added Builder flag), but because it involves additional dependencies there is also the option to disable it at compile time. If disabled at compile time, the runtime option becomes a no-op. Demangling currently happens in a single location inside the Symbolizer type. This has the advantage of concentrating the feature's implementation. However, it means that we need to bubble up the inferred language from all resolvers -- something that the recently added IntSym type helps us with. Closes: libbpf#50 Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
to d-e-s-o/blazesym
that referenced
this issue
Jul 24, 2023
TODO: Need more tests for different languages. This change adds support for transparent demangling of symbols. Demangling is generally runtime configurable (via the previously added Builder flag), but because it involves additional dependencies there is also the option to disable it at compile time. If disabled at compile time, the runtime option becomes a no-op. Demangling currently happens in a single location inside the Symbolizer type. This has the advantage of concentrating the feature's implementation. However, it means that we need to bubble up the inferred language from all resolvers -- something that the recently added IntSym type helps us with. Closes: libbpf#50 Signed-off-by: Daniel Müller <[email protected]>
danielocfb
pushed a commit
to danielocfb/blazesym
that referenced
this issue
Jul 25, 2023
TODO: Need more tests for different languages. This change adds support for transparent demangling of symbols. Demangling is generally runtime configurable (via the previously added Builder flag), but because it involves additional dependencies there is also the option to disable it at compile time. If disabled at compile time, the runtime option becomes a no-op. Demangling currently happens in a single location inside the Symbolizer type. This has the advantage of concentrating the feature's implementation. However, it means that we need to bubble up the inferred language from all resolvers -- something that the recently added IntSym type helps us with. Note that this change only provides *de*mangling support. That is, it hooks into the APIs mapping addresses to human readable symbols. The inverse, mapping human readable and potentially *un*mangled symbols to their mangled counterparts and then to addresses is not currently being done (that would be a useful addition to the inspect module, but is out of the scope of this change). Closes: libbpf#50 Signed-off-by: Daniel Müller <[email protected]>
danielocfb
pushed a commit
to danielocfb/blazesym
that referenced
this issue
Jul 26, 2023
This change adds support for transparent demangling of symbols. Demangling is generally runtime configurable (via the previously added Builder flag), but because it involves additional dependencies there is also the option to disable it at compile time. If disabled at compile time, the runtime option becomes a no-op. Demangling currently happens in a single location inside the Symbolizer type. This has the advantage of concentrating the feature's implementation. However, it means that we need to bubble up the inferred language from all resolvers -- something that the recently added IntSym type helps us with. Note that this change only provides *de*mangling support. That is, it hooks into the APIs mapping addresses to human readable symbols. The inverse, mapping human readable and potentially *un*mangled symbols to their mangled counterparts and then to addresses is not currently being done (that would be a useful addition to the inspect module, but is out of the scope of this change). Closes: libbpf#50 Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
to d-e-s-o/blazesym
that referenced
this issue
Jul 26, 2023
This change adds support for transparent demangling of symbols. Demangling is generally runtime configurable (via the previously added Builder flag), but because it involves additional dependencies there is also the option to disable it at compile time. If disabled at compile time, the runtime option becomes a no-op. Demangling currently happens in a single location inside the Symbolizer type. This has the advantage of concentrating the feature's implementation. However, it means that we need to bubble up the inferred language from all resolvers -- something that the recently added IntSym type helps us with. Note that this change only provides *de*mangling support. That is, it hooks into the APIs mapping addresses to human readable symbols. The inverse, mapping human readable and potentially *un*mangled symbols to their mangled counterparts and then to addresses is not currently being done (that would be a useful addition to the inspect module, but is out of the scope of this change). Closes: libbpf#50 Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
to d-e-s-o/blazesym
that referenced
this issue
Jul 26, 2023
This change adds support for transparent demangling of symbols. Demangling is generally runtime configurable (via the previously added Builder flag), but because it involves additional dependencies there is also the option to disable it at compile time. If disabled at compile time, the runtime option becomes a no-op. Demangling currently happens in a single location inside the Symbolizer type. This has the advantage of concentrating the feature's implementation. However, it means that we need to bubble up the inferred language from all resolvers -- something that the recently added IntSym type helps us with. Note that this change only provides *de*mangling support. That is, it hooks into the APIs mapping addresses to human readable symbols. The inverse, mapping human readable and potentially *un*mangled symbols to their mangled counterparts and then to addresses is not currently being done (that would be a useful addition to the inspect module, but is out of the scope of this change). Closes: libbpf#50 Signed-off-by: Daniel Müller <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should evaluate whether to add support to demangling of symbols from languages such as C++ or Rust as part of the symbolization process. It's not entirely clear whether it makes sense to integrate that into the library, given that it basically could be done entirely as a close-to-trivial post processing step (with the likes of https://crates.io/crates/symbolic-demangle), but it may be beneficial to do so if we aim to be a completely batteries-included solution.
The text was updated successfully, but these errors were encountered: