Skip to content

Stabilize -Zsymbol-mangling-version / RFC2603? #77116

Closed
@jsgf

Description

@jsgf
Contributor

Where are we with stabilizing RFC2603 and the -Zsymbol-mangling-version? Can we introduce -Csymbol-mangling-version?

(Note, I'm not thinking about changing the default from legacy yet, but we can also discuss that.)

cc @eddyb @michaelwoerister

Activity

tesuji

tesuji commented on Sep 23, 2020

@tesuji
Contributor

Why? What's the use case for it if it only has one stable option?

jonas-schievink

jonas-schievink commented on Sep 23, 2020

@jonas-schievink
Contributor

Stabilizing -Csymbol-mangling-version would imply stabilizing both the RFC 2603 mangling as well as the currently used legacy mangling, which does not seem like a good idea to me.

jsgf

jsgf commented on Sep 24, 2020

@jsgf
ContributorAuthor

I guess that's a question of what it means for the mangling to be "stable". Since Rust has no ABI guarantees, there's nothing in principle preventing either mangling scheme from changing from release to release. But since it's also an interface to other tools they need to be managed in a somewhat sensible way.

Legacy mangling gets away with this because it looks enough like typical C++ mangling for tools to show something useful (to a greater or lesser extent).

"v0" mangling needs more tool support to get good results, so there's a question of how well that support has been propagated (eg gdb and binutils has support for it upstream now, I think, but I don't know about current state of other tooling). Also if we extend v0 mangling to support new language features, will those demanglers degrade gracefully? (AFAIK @eddyb implemented them all, so I'm reasonably sure they will have taken that into consideration.)

So I think there's probably quite a few users which are currently relying on "legacy" as part of their environment, and have been for some time, so in that sense it is "stable". But we've been using "v0" for its richer type info for 1 year+, but its awkward that we need to invoke rustc in a nightly-like way to get it.

I'm also concerned that people are overlooking v0 mangling with the potential to introduce bugs, so we need to make sure its on equal footing with respect to regression testing etc.

So from my POV it makes sense to stabilize the option but retain the existing behaviour, until we're in the position to flip the default.

I think the counterargument would be that v0 mangling has some clear flaw and will need to be revised, in which case we should do a v1 and stabilize that. But I haven't seen anything to that effect. v0 - being a lot more inforation rich - is also a lot larger, but I don't know how much of a concern that is in practice.

added
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
on Sep 25, 2020
tmiasko

tmiasko commented on Jan 14, 2022

@tmiasko
Contributor

-C symbol-mangling-version=v0 was stabilized in #90128.

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

    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

      No branches or pull requests

        Participants

        @jsgf@jonas-schievink@tesuji@LeSeulArtichaut@tmiasko

        Issue actions

          Stabilize -Zsymbol-mangling-version / RFC2603? · Issue #77116 · rust-lang/rust