{"action":"created","issue":{"url":"https://api.github.com/repos/rust-lang/rfcs/issues/2603","repository_url":"https://api.github.com/repos/rust-lang/rfcs","labels_url":"https://api.github.com/repos/rust-lang/rfcs/issues/2603/labels{/name}","comments_url":"https://api.github.com/repos/rust-lang/rfcs/issues/2603/comments","events_url":"https://api.github.com/repos/rust-lang/rfcs/issues/2603/events","html_url":"https://github.com/rust-lang/rfcs/pull/2603","id":384795141,"node_id":"MDExOlB1bGxSZXF1ZXN0MjMzOTEwOTQy","number":2603,"title":"RFC: Symbol Mangling v2","user":{"login":"michaelwoerister","id":1825894,"node_id":"MDQ6VXNlcjE4MjU4OTQ=","avatar_url":"https://avatars2.githubusercontent.com/u/1825894?v=4","gravatar_id":"","url":"https://api.github.com/users/michaelwoerister","html_url":"https://github.com/michaelwoerister","followers_url":"https://api.github.com/users/michaelwoerister/followers","following_url":"https://api.github.com/users/michaelwoerister/following{/other_user}","gists_url":"https://api.github.com/users/michaelwoerister/gists{/gist_id}","starred_url":"https://api.github.com/users/michaelwoerister/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/michaelwoerister/subscriptions","organizations_url":"https://api.github.com/users/michaelwoerister/orgs","repos_url":"https://api.github.com/users/michaelwoerister/repos","events_url":"https://api.github.com/users/michaelwoerister/events{/privacy}","received_events_url":"https://api.github.com/users/michaelwoerister/received_events","type":"User","site_admin":false},"labels":[{"id":1137548191,"node_id":"MDU6TGFiZWwxMTM3NTQ4MTkx","url":"https://api.github.com/repos/rust-lang/rfcs/labels/A-linkage","name":"A-linkage","color":"f7e101","default":false},{"id":211667955,"node_id":"MDU6TGFiZWwyMTE2Njc5NTU=","url":"https://api.github.com/repos/rust-lang/rfcs/labels/T-compiler","name":"T-compiler","color":"bfd4f2","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":18,"created_at":"2018-11-27T13:29:21Z","updated_at":"2018-12-01T16:38:24Z","closed_at":null,"author_association":"NONE","pull_request":{"url":"https://api.github.com/repos/rust-lang/rfcs/pulls/2603","html_url":"https://github.com/rust-lang/rfcs/pull/2603","diff_url":"https://github.com/rust-lang/rfcs/pull/2603.diff","patch_url":"https://github.com/rust-lang/rfcs/pull/2603.patch"},"body":"[Rendered](https://github.com/michaelwoerister/rfcs/blob/symbol-mangling/text/0000-symbol-name-mangling-v2.md)\r\n[Reference Implementation](https://github.com/michaelwoerister/std-mangle-rs)\r\n[Pre-RFC](https://internals.rust-lang.org/t/pre-rfc-a-new-symbol-mangling-scheme/8501)\r\n\r\n\r\n# Summary \r\n\r\nThis RFC proposes a new mangling scheme that describes what the symbol names generated by the Rust compiler. This new scheme has a number of advantages over the existing one which has grown over time without a clear direction. The new scheme is consistent, does not depend on compiler internals, and the information it stores in symbol names can be decoded again which provides an improved experience for users of external tools that work with Rust symbol names. The new scheme is based on the name mangling scheme from the [Itanium C++ ABI][itanium-mangling].\r\n\r\n# Motivation\r\n\r\nDue to its ad-hoc nature, the compiler's current name mangling scheme has a\r\nnumber of drawbacks:\r\n\r\n- It depends on compiler internals and its results cannot be replicated by another compiler implementation or external tool.\r\n- Information about generic parameters and other things is lost in the mangling process. One cannot extract the type arguments of a monomorphized function from its symbol name.\r\n- The current scheme is inconsistent: most paths use Itanium style encoding, but some don't.\r\n- The symbol names it generates can contain `.` characters which is not generally supported on all platforms. \\[[1][gas]\\]\\[[2][lld-windows-bug]\\]\\[[3][thin-lto-bug]\\]\r\n\r\n[gas]: https://sourceware.org/binutils/docs/as/Symbol-Names.html#Symbol-Names\r\n[lld-windows-bug]: https://github.com/rust-lang/rust/issues/54190\r\n[thin-lto-bug]: https://github.com/rust-lang/rust/issues/53912\r\n\r\nThe proposed scheme solves these problems:\r\n\r\n- It is defined in terms of the language, not in terms of compiler data-structures that can change at any given point in time.\r\n- It encodes information about generic parameters in a reversible way.\r\n- It has a consistent definition that does not rely on pretty-printing certain language constructs.\r\n- It generates symbols that only consist of the characters `A-Z`, `a-z`, `0-9`, and `_`.\r\n\r\nThis should make it easier for third party tools to work with Rust binaries."},"comment":{"url":"https://api.github.com/repos/rust-lang/rfcs/issues/comments/443438991","html_url":"https://github.com/rust-lang/rfcs/pull/2603#issuecomment-443438991","issue_url":"https://api.github.com/repos/rust-lang/rfcs/issues/2603","id":443438991,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0MzQzODk5MQ==","user":{"login":"zackw","id":325899,"node_id":"MDQ6VXNlcjMyNTg5OQ==","avatar_url":"https://avatars0.githubusercontent.com/u/325899?v=4","gravatar_id":"","url":"https://api.github.com/users/zackw","html_url":"https://github.com/zackw","followers_url":"https://api.github.com/users/zackw/followers","following_url":"https://api.github.com/users/zackw/following{/other_user}","gists_url":"https://api.github.com/users/zackw/gists{/gist_id}","starred_url":"https://api.github.com/users/zackw/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zackw/subscriptions","organizations_url":"https://api.github.com/users/zackw/orgs","repos_url":"https://api.github.com/users/zackw/repos","events_url":"https://api.github.com/users/zackw/events{/privacy}","received_events_url":"https://api.github.com/users/zackw/received_events","type":"User","site_admin":false},"created_at":"2018-12-01T16:38:24Z","updated_at":"2018-12-01T16:38:24Z","author_association":"CONTRIBUTOR","body":"@michaelwoerister Replying to some of your notes, out of order:\r\n\r\n>  In my opinion it is not the demangler's job to verify that identifiers conform to the Rust spec. It should just print something human-readable.\r\n\r\nIMO it's not a matter of verification, it's a matter of ensuring unambiguous demangling.  Suppose you have an object file that defines the ill-formed symbol `_RN15mycrate_4a3b56d9godel_fgdu6escher4bachVE`, it's important _not_ to demangle that as `mycrate[4a3b56d]::gödel::escher::bach`, because that is the demangling of the well-formed symbol `_RN15mycrate_4a3b56d8gdel_Fqau6escher4bachVE`, and someone trying to track down a link error will be baffled as to why they don't match.  Demanglers need to cope with ill-formed symbols, because demanglers are debugging aids, and that includes debugging the compiler.\r\n\r\n> ABI markers ...\r\n\r\n * I like the idea of allowing an arbitrary <identifier> after the K.\r\n * Shorthand notation for `extern \"C\"` is fine and all, but it's important for there to be _only one name_ for each ABI.  For instance, is there any difference between \"c\" and \"x\" on Linux/x86-64?  If not, we should have only one of them.\r\n * I don't feel super strongly about this but, if you have a random symbol that you're pasting into a web demangler, is the distinction between \"MSP430 interrupt handler\" and \"x86 interrupt handler\" really important?  You probably already know which CPU you are reverse engineering something from.\r\n\r\n> The symbol-hash, that is part of every symbol name in the current mangling scheme, includes the function parameters since at least 2015, if not longer. Yet, in all that time I personally have never seen a linker error catching a mismatch this way. So I am a bit doubtful whether encoding function parameters in symbol names would have a practical purpose (at least as far as safety is concerned).\r\n\r\nI could live without including the full type signature, but I think both @eddyb and you are underestimating the probability of a type clash going undetected under this proposal, particularly when we start talking about cross-language interop and alternative implementations of the Rust compiler (which may have different sets of bugs).\r\n\r\nKeep in mind that if there's a hash collision (which is the case where it would matter), you would _not_ see  a linker error; the program would appear to link successfully, and then malfunction at runtime.  I don't know how the existing hashes are computed; I presume they are cryptographically strong.  Per-symbol hashes are the full hash and they do include the type signature, so collisions are unlikely.  But crate disambiguator hashes (whether or not they include the full type signature of each symbol) are truncated to only a few hex digits, which makes collisions possible again, even though the hash is strong.  So the proposed scheme is significantly weaker at detecting this type of error than the current one."}}
{"actor":{"display_login":"zackw"}}