symbol names do not include enough information to identify specializations

[froydnj]

When looking at symbols in Stylo today, I stumbled upon:

0x1c01c FUNC    LOCAL  DEFAULT   11 _$LT$style..properties..PropertyDeclaration$u20$as$u20$style_traits..values..ToCss$GT$::to_css::hf4dc63cd1d21296c
83152 FUNC    LOCAL  DEFAULT   11 _$LT$style..properties..PropertyDeclaration$u20$as$u20$style_traits..values..ToCss$GT$::to_css::h4cd1bbb5253aecc6
56128 FUNC    LOCAL  DEFAULT   11 _$LT$style..properties..PropertyDeclaration$u20$as$u20$style_traits..values..ToCss$GT$::to_css::h95e73bec7530a735

which initially looked like rustc had duplicated functions (modulo the hashes tacked on at the end). I eventually figured out that they were from:

pub trait ToCss {
    /// Serialize `self` in CSS syntax, writing to `dest`.
    fn to_css<W>(&self, dest: &mut W) -> fmt::Result where W: Write;
    // ...other things elided
}

and implementations of said trait. But that's still not much help, because I can't figure out without a lot of tedium which specializations of W are producing which of the above symbols.

I realize C++ symbol names are often long and gross, but they nearly always include enough information to tell you exactly what code you should be looking at. Symbols from rustc often leave out important bits of information, which makes some forms of analysis much more difficult than they ought to be. (You could, if you were so inclined, get some of this information from debug info, but trawling through debug info is its own brand of tedium.)

[m4b]

Those particular symbols aren't well-mangled symbols, did you truncate them or did they appear just as they are above? What version of rust was servo compiled with?

You can verify this by taking the name and doing:

echo '_$LT$style..properties..PropertyDeclaration$u20$as$u20$style_traits..values..ToCss$GT$::to_css::hf4dc63cd1d21296c` | c++filt

assuming c++filt is installed on your system. If it isn't you can try the pure rust version of a c++/rust demangler.

(the single quotes are important if you are in a shell as the $ will be interpreted in double quotes "; I intend to raise an issue about ergonomics here)

[sfackler]

@m4b what does c++filt's ability to parse Rust symbol names have to do with anything? Our mangling isn't compatible with C++'s.

[m4b]

@sfackler You'll be happy to know that it is! https://github.com//m4b/rust/blob/383e313d181eceb3155eb1089d448144f830ee23/src/librustc_trans/back/symbol_names.rs#L350

Just run c++filt on output of nm or your favorite symbol output program and it should display correctly

[sfackler]

Given that the symbols listed above don't demangle with c++filt it seems like that comment may not be accurate.

[m4b]

I've never seen symbols like that; they are definitely broken regardless if that's how they are in the binary; they haven't gone through the sanitizer:

_$LT$style..properties..PropertyDeclaration$u20$as$u20$style_traits..values..ToCss$GT$::to_css::hf4dc63cd1d21296c

note the double ::'s in the symbol name:

https://github.com//m4b/rust/blob/383e313d181eceb3155eb1089d448144f830ee23/src/librustc_trans/back/symbol_names.rs#L424

[m4b]

Actually, @froydnj I bet you already ran something like c++filt on the output already, and pasted it here, didn’t you ?

I’m very curious to see the original symbol if so, as I suspect it isn’t conforming to mangling standard.

EDIT

So, my new guess is that they're:

1. On OSX, or they used cppfilt
2. the output of echo '_ZN33_$LT$alloc..arc..Arc$LT$T$GT$$GT$9drop_slow17h9ed4cba808ccbc62E' | c++filt on OSX will not be: <alloc::arc::Arc<T>>::drop_slow but _$LT$alloc..arc..Arc$LT$T$GT$$GT::drop_slow::17h9ed4cba808ccbc62

E.g.:

echo '_ZN33_$LT$alloc..arc..Arc$LT$T$GT$$GT$9drop_slow17h9ed4cba808ccbc62E' | c++filt
<alloc::arc::Arc<T>>::drop_slow

echo '_ZN33_$LT$alloc..arc..Arc$LT$T$GT$$GT$9drop_slow17h9ed4cba808ccbc62E' | cppfilt 
_$LT$alloc..arc..Arc$LT$T$GT$$GT$::drop_slow::h9ed4cba808ccbc62

I dunno who is right and who is wrong ;) I'm going to sleep

[froydnj]

I don't remember whether I ran c++filt or equivalent on the output originally. I tried to find the symbols in a Nightly build of Firefox and had some success:

froydnj@hawkeye:/opt/build/froydnj/build-gcc$ readelf -sW ~/firefox/libxul.so|grep to_css | sort -k 3 -n -r |head -n 3 | awk '{print $3, $4, $5, $6, $8}'
86353 FUNC LOCAL DEFAULT _ZN86_$LT$style..properties..PropertyDeclaration$u20$as$u20$style_traits..values..ToCss$GT$6to_css17hd071bc295407688aE
55138 FUNC LOCAL DEFAULT _ZN86_$LT$style..properties..PropertyDeclaration$u20$as$u20$style_traits..values..ToCss$GT$6to_css17h2784d2352282c691E
34708 FUNC LOCAL DEFAULT _ZN86_$LT$style..properties..PropertyDeclaration$u20$as$u20$style_traits..values..ToCss$GT$6to_css17h82a7434b34298b9bE

Those symbols are definitely untouched by c++filt. In any event, there's no good way to trace them back to the source code from the symbol names alone.

[RazrFalcon]

Look like this is the same issue as this:

fn main() {
    method_t(5);
    method_t(5.5);
}

fn method_t<T: Debug>(v: T) {
    println!("{:?}", v);
}

This will be mangled to:

test_crate::method_t::h6162eaf340852a5e
test_crate::method_t::h28b0347ca3fd97b7

So there is no way to distinguish them because they don't have type info in the name.

[fitzgen]

Including the instantiation's types in the symbol would be super useful to twiggy, which can find and list monomorphizations of generic functions^*, but it is fairly unactionable because the symbols only differ in the hash. Would be a lot more actionable if the types were included in the symbol.

^* For example:

$ twiggy monos path/to/input.wasm
 Apprx. Bloat Bytes │ Apprx. Bloat % │ Bytes │ %     │ Monomorphizations
────────────────────┼────────────────┼───────┼───────┼────────────────────────────────────────────────────────
               1977 ┊          3.40% ┊  3003 ┊ 5.16% ┊ alloc::slice::merge_sort
                    ┊                ┊  1026 ┊ 1.76% ┊     alloc::slice::merge_sort::hb3d195f9800bdad6
                    ┊                ┊  1026 ┊ 1.76% ┊     alloc::slice::merge_sort::hfcf2318d7dc71d03
                    ┊                ┊   951 ┊ 1.63% ┊     alloc::slice::merge_sort::hcfca67f5c75a52ef
               1302 ┊          2.24% ┊  3996 ┊ 6.87% ┊ <&'a T as core::fmt::Debug>::fmt
                    ┊                ┊  2694 ┊ 4.63% ┊     <&'a T as core::fmt::Debug>::fmt::h1c27955d8de3ff17
                    ┊                ┊   568 ┊ 0.98% ┊     <&'a T as core::fmt::Debug>::fmt::hea6a77c4dcddb7ac
                    ┊                ┊   433 ┊ 0.74% ┊     <&'a T as core::fmt::Debug>::fmt::hfbacf6f5c9f53bb2
                    ┊                ┊   301 ┊ 0.52% ┊     <&'a T as core::fmt::Debug>::fmt::h199e8e1c5752e6f1

[lu-zero]

Another similar issue here

[steveklabnik]

Triage: I know that we've changed our name mangling implementation, but am unsure if it includes this info or not. I think @eddyb would know?

[eddyb]

I think "specializations" in the title should be "instantiations" (the former confused me at first).

And we haven't changed the mangling yet, or at least not the default.
You need -Z symbol-mangling-version=v0 right now to get the new mangling.

But all such information should be there in the new mangling.

[Mark-Simulacrum]

I'm going to close this as v0 will (does, if used, which is possible on stable) include this information, doesn't seem warranted to have a separate issue essentially tracking that becoming stable.