Enabling v0 mangling by default

Background

rustc has historically used Itanium name mangling for Rust code. This has worked fairly well as many system level tools such as debuggers, profilers, and tracing tools have support for demangling Itanium symbol names however, not all Rust symbol information can be encoded accurately in the Itanium mangling system.

As a result, a Rust specific mangling system was created. This system allows more detailed information to be encoded in the symbol name but is not compatible with Itamium demanglers so external tools must be taught how to demangle Rust symbols.

rustc currently defaults to using the original Itanium mangling system (called legacy) but users can opt-in to compiling their code with the new system by passing -Csymbol-mangling-version=v0.

Timeline

• 2019-05-10: Rust v0 symbol mangling RFC accepted.
• 2019-05-31: rust#57967 added support for v0 mangling on nightly.
• 2021-10-23: rustc defaults to building itself with v0 mangling via rust#90054.
• 2022-01-02: -Zsymbol-mangling-version=v0 was stabilized as -Csymbol-mangling-version=v0 in rust#90128.

When do we turn on v0 mangling by default?

The main consideration for deciding when the time to flip this switch seems to be determining how much breakage in the wider tool ecosystem is acceptable. (Please mention other concerns if I've missed something!)

For the major Tier 1 platforms:

Linux

• binutils
  • Provided by libiberty 11.0 as part of gcc gcc 11, shipped 2021-04-27.
• gdb
  • Provided by libiberty 11.0 as part of gcc gcc 11, shipped 2021-04-27.
• lldb
  • Not supported, but lldb does not generally support Rust specific features anyway.
• perf
  • Provided by libiberty 11.0 as part of gcc gcc 11, shipped 2021-04-27.
• valgrind
  • Valgrind 3.19, shipped 2022-04-11.
• others?

Windows

Windows contains no special support for demangling either Itanium symbol names or Rust v0 ones. As such, debug symbols (PDBs) are required to show user friendly symbol names for either system.

The Rust@MS team's consensus is that there are no blockers to turning v0 mangling on for Windows

macOS

I'm not currently aware of any user reports for the following applications:

• XCode/Instruments
• lldb
  • We know lldb does not support demangling v0 symbols.
• dtrace
  • Is dtrace used enough to be considered?
• others?

Of particular interest is whether tooling will use debuginfo to provide user friendly symbol names or if it always relies on a demangler. If the former, we're probably in pretty good shape but if the latter, it's unclear what we can do to resolve things.

Question Queue

• [mw] Addition concern: increased compile times (see this perf run)

• [jyn] Do we have a contact at Apple we can talk to to see what their priority is for this? Has someone tested whether the MacOS tools break today?

• [jyn] Does rust-lldb at least support v0 mangling?

Action items

• create list of distros/versions from meeting poll results
• investigate llvm support for v0 mangling
• consider creating a standard test file with various v0 symbols to validate the various demangler implementations