-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only emit forward compatible v0 symbol names with graceful degradation #737
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed. Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:
Concerns can be lifted with:
See documentation at https://forge.rust-lang.org cc @rust-lang/compiler @rust-lang/compiler-contributors |
… r=<try> [perf] Test performance with v0 symbol mangling scheme being the default With the wider ecosystem getting close to support the v0 mangling scheme and LLD as the default linker addressing v0's main performance issue, it is getting more likely that we can soon make v0 the default. This PR's purpose is to collect current performance numbers and also to serve as a baseline for gauging the performance impact of [MCP 737](rust-lang/compiler-team#737). v0 symbol mangling tracking issue: rust-lang#60705 r? `@ghost`
[do not merge] Proof of concept implementation of forward compatible v0 symbols (MCP 737) This PR changes v0 symbol names to enable graceful degradation for demanglers that don't support newer language features yet (as described in [MCP 737](rust-lang/compiler-team#737)). The corresponding changes in rustc-demangle are at https://github.com/michaelwoerister/rustc-demangle/tree/skip_unknown. This proof-of-concept implementation is meant to help evaluating if MCP 737 is viable. r? `@ghost`
We discussed this in the design meeting on Jun 14 and decided to not pursue this approach any further. Instead we'll document the policy that breaking changes can occur due to addition to the grammar (which are usually necessary only for some new language features). |
Proposal
The long time it takes for downstream tooling like GDB, perf, or valgrind to pick up support for changes in the v0 symbol mangling grammar has been the only real reason why v0 mangling is not the standard yet. This is not the fault of these tools, but rather a side effect of long-lived Linux distros sticking to a particular version of these tools for many years. This MCP proposes to mitigate the problem by using the existing v0 grammar in a way that allows graceful degradation:
C<decimal number>_<mangled contents>
production, where the decimal is the number of bytes in<mangled contents>
plus the_
.<mangled contents>
is a v0 fragment containing newer grammar elements. To a current demangler, this will look like a regular crate-root production and it will demangle it as if_<mangled contents>
was an identifier. This works because the identifier production can contain arbitrary content and the decimal prefix allows it to skip ahead.C<decimal number>_
prefix. If they encounter it, they will try to demangle the contents. If that succeeds, great! If not, they can print the contents verbatim or some kind of placeholder.The overall effect is that of graceful degradation. Old demanglers will show a mostly correct name, except for the generic parameters or types they don't understand.
Example
The symbol name
my_crate::foo<{ (1i64, 2i64, 3i64) }>
is mangled to_RINxC8my_crate3fooKTx1_x2_x3_EE
according to the const generics additions proposed in rust-lang/rfcs#3161. Current demanglers will just fail to demangle this.With the mitigation, it would be mangled to
_RINxC8my_crate3fooC13_KTx1_x2_x3_EE
(notice the addedC13_
before the generic parameter). A current demangler will demangle this asmy_crate::foo<_KTx1_x2_x3_E>
. A newer demangler will be able to fully reconstruct the originalmy_crate::foo<{ (1i64, 2i64, 3i64) }>
.I expect that for complex symbol names with deeply nested generic arguments, getting a best effort demangling is a welcome improvement over just the mangled name.
The proposed solution is one possibility (inspired by @eddyb's proposol for dealing with
f16
in rust-lang/rust#122106 (comment)). I'd be happy to hear other ideas.Mentors or Reviewers
None yet.
Process
The main points of the Major Change Process are as follows:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
The text was updated successfully, but these errors were encountered: