Rust demangle

[zokier]

Resolves #110

Not quite yet ready for merge, but posting it early for feedback

CMake build scripts do not work right, for some reason I get this error if the rust lib hasn't been built

make[2]: *** No rule to make target 'third_party/rustc-demangle/target/release/librustc_demangle.a', needed by 'bloaty'.  Stop.

As a workaround building the library manually resolves the error. This is bit confusing to me as the documentation for add_custom_command says "In makefile terms this creates a new target..", so the target should be there? I would appreciate any help/hints here.

Not sure if rustc-demangle should also be built in debug mode when bloaty is built in debug mode. Now for simplicity's sake I'm building rustc-demangle always in release mode.

Need to add tests for this new feature.

Now I've only added Rust demangling to src/elf.cc, it should be also added similarly to src/macho.cc. I don't have a Mac at hand though, so need to tread bit more carefully there.

Currently the submodule is pointing to my fork of rustc-demangle, but that can be changed to refer upstream once rust-lang/rustc-demangle#14 is merged

Should document this feature in README.md.

Does Travis need some new configuration for testing also this feature in CI?

[haberman]

Nice!

I asked about demangling on Rust Internals: https://internals.rust-lang.org/t/symbol-mangling-of-rust-vs-c/7222

I got a reply that said that Rust symbols always end in a 16 byte hash. So perhaps we could detect Rust symbols by simply looking for the string "17h" 16 byte before the end of the string? Want to see if that works as intended?

I'd really like to do this in a way that doesn't require Rust-specific options if possible. This would be more user-friendly, and also would gracefully support mixed C++/Rust binaries.

[zokier]

I'll try to that out. It is bit hacky, but I can see the benefit of avoiding Rust specific modes.

What would be the desired behavior if we detect Rust symbol and we don't have rustc-demangle compiled in? Try to demangle with C++ demangler or use the mangled symbol as-is?

Btw, do we want to have those hashes in demangled symbols? Right now I have opted to not have them, but rustc-demangle can do either way. I think (but honestly I'm not sure) the hashes are there to make symbols unique in situations where we have multiple versions of a library linked into one binary, so I guess leaving the hashes out leads to different results in such cases.

[haberman]

What would be the desired behavior if we detect Rust symbol and we don't have rustc-demangle compiled in? Try to demangle with C++ demangler or use the mangled symbol as-is?

Good question. I'd be inclined to say use C++ demangling. Users can always get raw symbols with rawsymbols if they want them.

What do you think as a Rust user?

[zokier]

I think using C++ demangling sounds pretty reasonable, maybe emit a warning to stderr also?

[haberman]

Sounds good, as long as it's just a single warning per invocation.

[haberman]

Just checking in, I think this is in your court? I wanted to make sure you're not waiting on me for anything.

[jminer]

Rust is switching to a new symbol mangling scheme:

https://github.com/rust-lang/rfcs/blob/master/text/2603-symbol-name-mangling-v2.md

It has been implemented but is not turned on by default yet. In the new scheme, all Rust symbols start with _R so they can't conflict with C++ symbols. Here's the tracking issue that will be updated when the new scheme is turned on by default:

rust-lang/rust#60705

I saw a comment that they also wrote a complete C implementation of the new scheme, but I can't find a link to it anywhere.

[haberman]

Cool, if/when this is available as a C library I'd be happy to integrate it.

[msizanoen1]

Maybe this? https://gist.github.com/eddyb/c41a69378750a433767cf53fe2316768

[eddyb]

I saw a comment that they also wrote a complete C implementation of the new scheme, but I can't find a link to it anywhere.

@msizanoen1's link is correct, although I wish I got pinged on this issue (gist links aren't enough to do that). I'm in the process of finally upstreaming the whole thing to GCC (which sadly holds the primary copy of libiberty), after submitting several preparatory patches to them last year.

The current GCC/binutils/gdb implementation already avoids demangling Rust legacy symbols via the C++ demangler, but instead it handles them more like rustc-demangle does.
This means that in the "auto" mode, gdb (or even c++filt) will always try to demangle as Rust first before trying to demangle as C++.
(I'm not sure these changes have made it into a GCC/binutils/gdb release yet)

[eddyb]

I added the upstreaming effort status to rust-lang/rust#60705, and I'll post updates as comments on there, so you can subscribe to it if you want to track my progress.