Closed
Description
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.)
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
tesuji commentedon Sep 23, 2020
Why? What's the use case for it if it only has one stable option?
jonas-schievink commentedon Sep 23, 2020
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 commentedon Sep 24, 2020
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.
tmiasko commentedon Jan 14, 2022
-C symbol-mangling-version=v0
was stabilized in #90128.