Skip to content

Tracking issue for RFC 2603, "Rust Symbol Mangling (v0)" #60705

@Centril

Description

@Centril
Contributor

This is a tracking issue for the RFC "Rust Symbol Mangling (v0)" (rust-lang/rfcs#2603).

Current status:

Since #90128, you can control the mangling scheme with -C symbol-mangling-version, which can be:

  • legacy: the older mangling version, still the default currently
    • explicitly specifying this is unstable-only and also requires -Z unstable-options
      (to allow for eventual removal after v0 becomes the default)
  • v0: the new RFC mangling version, as implemented by Introduce Rust symbol mangling scheme. #57967

(Before #90128, this flag was the nightly-only -Z symbol-mangling-version)

To test the new mangling, set RUSTFLAGS=-Csymbol-mangling-version=v0 (or change rustflags in .cargo/config.toml). Please note that only symbols from crates built with that flag will use the new mangling, and that tool support (e.g. debuggers) will be limited initially, until everything is upstreamed. However, RUST_BACKTRACE and rustfilt should work out of the box with either mangling version.

Steps:

Unresolved questions:

Desired availability of tooling:

Linux:

  • Tools: binutils, gdb, lldb, perf, valgrind
Distro Has versions of all tools with support?
Debian (latest stable) ?
Arch ?
Ubuntu (latest release) ?
Ubuntu (latest LTS) ?
Fedora (latest release) ?
Alpine (latest release) ?

Windows:

Windows does not have support for demangling either legacy or v0 Rust symbols and requires debuginfo to load the appropriate function name. As such, no special support is required.

macOS:

More investigation is needed to determine to what extent macOS system tools already support Rust v0 mangling.

Activity

added
B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
on May 10, 2019
eddyb

eddyb commented on May 13, 2019

@eddyb
michaelwoerister

michaelwoerister commented on May 13, 2019

@michaelwoerister
eddyb

eddyb commented on May 14, 2019

@eddyb
added
B-RFC-implementedBlocker: Approved by a merged RFC and implemented but not stabilized.
and removed
B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.
on Jun 9, 2019
robinmoussu

robinmoussu commented on Dec 27, 2019

@robinmoussu

I just opened a bug in compiler-explorer because I noticed collision in the demangled name of different monomorphisation of the same function. As far as I understand, the current mangling scheme of rust still use the v1 witch doesn't contains the required information, while this proposed v2 would solved it? Did I correctly understood what the current situation is?

142 remaining items

danobi

danobi commented on Jan 29, 2025

@danobi
Contributor

As a heads up, perf is about to drop support for libbfd/libiberty for license incompatibility reasons. I think someone needs to go and teach perf how to demangle v0 symbols. More details here: https://lore.kernel.org/bpf/gnwmibvjtwboisw7uv32bdo4ziw4qzgwzvndqg2czpa6vp4olv@44n36ndbwobc/

captain5050

captain5050 commented on Jan 29, 2025

@captain5050

As a heads up, perf is about to drop support for libbfd/libiberty for license incompatibility reasons. I think someone needs to go and teach perf how to demangle v0 symbols.

I sent:
https://lore.kernel.org/lkml/20250129193037.573431-1-irogers@google.com/
for this. There are some TODOs in it and it is only lightly tested.

bjorn3

bjorn3 commented on Jan 29, 2025

@bjorn3
Member

Have you seen https://github.com/rust-lang/rustc-demangle/blob/main/crates/native-c/src/demangle.c? It is a C port of the official demangler with both v0 and legacy support.

captain5050

captain5050 commented on Jan 30, 2025

@captain5050

Have you seen https://github.com/rust-lang/rustc-demangle/blob/main/crates/native-c/src/demangle.c? It is a C port of the official demangler with both v0 and legacy support.

I hadn't seen it. Given the official nature, legacy support and lack of TODOs compared to my version, I would say it was very much superior :-). Perhaps @arielb1 could contribute it to Linux perf? I'd be happy to try to co-develop if useful.

Wrt licenses, MIT is explicitly compatible and Apache 2 is compatible if combined with a compatible license under an OR license which I believe agrees with the wording here and is already in use by other files.

So outside of formatting things, I think the code can be added as is with the addition of a "SPDX-License-Identifier: Apache-2.0 OR MIT" comment at the top. There is a Linux kernel code contribution tool that will warn on formatting issues called checkpatch.pl.

captain5050

captain5050 commented on Feb 10, 2025

@captain5050

Hi, wondered if there is any update? On the LKML thread it seems preferred to pull the code into the Linux tree rather than depend on a library (at least initially). If I did this I'm happy to add co-authored tags - I'm also happy to guide others to do the work. What's best? I'm happy to do the fairly trivial glue code. I worry given the need to stand up and make a decisions there's the potential for this issue to sit unresolved. Would love @arielb1's input given they wrote the code.

lolbinarycat

lolbinarycat commented on Apr 10, 2025

@lolbinarycat
Contributor

I un-checked the box for perf since it uses its own demangler (https://github.com/torvalds/linux/blob/master/tools/perf/util/demangle-rust.c) instead of deferring to a library as previously stated.

as bjorn mentioned, there is a C version of the demangler, it just needs someone to write up a patch to integrate it into perf.

captain5050

captain5050 commented on Apr 29, 2025

@captain5050

as bjorn mentioned, there is a C version of the demangler, it just needs someone to write up a patch to integrate it into perf.

I wrote the patches and sent them to LKML, thanks to all and @arielb1 that the work builds from. Please let me know how I can improve the patches on the Linux mailing list:
https://lore.kernel.org/lkml/20250429185839.1807005-1-irogers@google.com/
For example, when adding the v0 demangling tests I switched to the alternate=true encoding as that better matched:
https://lore.kernel.org/lkml/20250429185839.1807005-5-irogers@google.com/
Thanks.

arielb1

arielb1 commented on Jul 9, 2025

@arielb1
Contributor

Just noticed the issue now, sorry. Is there any help that is still needed?

If the question is about the alternate vs. non-alternate format - do whatever fits your case better. The alternate format is more verbose but preserves more information.

captain5050

captain5050 commented on Jul 9, 2025

@captain5050
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-name-manglingArea: name mangling / decorationB-RFC-implementedBlocker: Approved by a merged RFC and implemented but not stabilized.B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCS-tracking-needs-to-bakeStatus: The implementation is "complete" but it needs time to bake.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @comex@eddyb@joshtriplett@pnkfelix@Amanieu

      Issue actions

        Tracking issue for RFC 2603, "Rust Symbol Mangling (v0)" · Issue #60705 · rust-lang/rust