https://bugs.kde.org/show_bug.cgi?id=445916
Bug ID: 445916
Summary: Demangle Rust v0 symbols with .llvm suffix
Product: valgrind
Version: 3.19 GIT
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
This was discussed as side issue in bug #445668
And is discussed in upstream rustc here:
https://github.com/rust-lang/rust/issues/60705
Relevant comments from bug #445668:
"_RNvMs0_NtCs5l0EXMQXRMU_21rustc_data_structures17obligation_forestINtB5_16ObligationForestNtNtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfill26PendingPredicateObligationE22register_obligation_atB1v_.llvm.8517020237817239694"
(*)
(*) BTW. What is this? It looks like a mangled Rust v0 symbol, but it isn't
because it (I also checked with c++filt) cannot be demangled.
The Rust compiler currently sometimes generates symbols with a
`.llvm.<numbers>` suffix. These violate the v0 spec, which doesn't allow '.'
chars, and the libiberty/Valgrind demangler doesn't demangle them. It's a
problem that needs to be fixed on the Rust side.
Going back to this (and I know it's a tangent), there's now some disagreement
about whether this needs to be fixed on the Rust side, or the
libiberty/Valgrind side:
https://github.com/rust-lang/rust/issues/60705#issuecomment-974011409 :(
Interesting. I see gcc "fixed" this (for c++ symbols) by translating those
suffixes to "[clone .constprop.2]", "[clone .isra.3]" or "[clone ._omp_fn.2]".
Which is nice if you want to know why there is a new (local) symbol for a code
range. But I think it would actually be fine to simply cut off anything after a
'.' or '$' and just demangle the part before it. For the user the important
thing is knowing which (source) function an address is associated with, not
which compiler transformation has been applied to it.
--
You are receiving this mail because:
You are watching all bug changes.
