rustc_symbol_mangling/lib.rs
1//! The Rust Linkage Model and Symbol Names
2//! =======================================
3//!
4//! The semantic model of Rust linkage is, broadly, that "there's no global
5//! namespace" between crates. Our aim is to preserve the illusion of this
6//! model despite the fact that it's not *quite* possible to implement on
7//! modern linkers. We initially didn't use system linkers at all, but have
8//! been convinced of their utility.
9//!
10//! There are a few issues to handle:
11//!
12//! - Linkers operate on a flat namespace, so we have to flatten names.
13//! We do this using the C++ namespace-mangling technique. Foo::bar
14//! symbols and such.
15//!
16//! - Symbols for distinct items with the same *name* need to get different
17//! linkage-names. Examples of this are monomorphizations of functions or
18//! items within anonymous scopes that end up having the same path.
19//!
20//! - Symbols in different crates but with same names "within" the crate need
21//! to get different linkage-names.
22//!
23//! - Symbol names should be deterministic: Two consecutive runs of the
24//! compiler over the same code base should produce the same symbol names for
25//! the same items.
26//!
27//! - Symbol names should not depend on any global properties of the code base,
28//! so that small modifications to the code base do not result in all symbols
29//! changing. In previous versions of the compiler, symbol names incorporated
30//! the SVH (Stable Version Hash) of the crate. This scheme turned out to be
31//! infeasible when used in conjunction with incremental compilation because
32//! small code changes would invalidate all symbols generated previously.
33//!
34//! - Even symbols from different versions of the same crate should be able to
35//! live next to each other without conflict.
36//!
37//! In order to fulfill the above requirements the following scheme is used by
38//! the compiler:
39//!
40//! The main tool for avoiding naming conflicts is the incorporation of a 64-bit
41//! hash value into every exported symbol name. Anything that makes a difference
42//! to the symbol being named, but does not show up in the regular path needs to
43//! be fed into this hash:
44//!
45//! - Different monomorphizations of the same item have the same path but differ
46//! in their concrete type parameters, so these parameters are part of the
47//! data being digested for the symbol hash.
48//!
49//! - Rust allows items to be defined in anonymous scopes, such as in
50//! `fn foo() { { fn bar() {} } { fn bar() {} } }`. Both `bar` functions have
51//! the path `foo::bar`, since the anonymous scopes do not contribute to the
52//! path of an item. The compiler already handles this case via so-called
53//! disambiguating `DefPaths` which use indices to distinguish items with the
54//! same name. The DefPaths of the functions above are thus `foo[0]::bar[0]`
55//! and `foo[0]::bar[1]`. In order to incorporate this disambiguation
56//! information into the symbol name too, these indices are fed into the
57//! symbol hash, so that the above two symbols would end up with different
58//! hash values.
59//!
60//! The two measures described above suffice to avoid intra-crate conflicts. In
61//! order to also avoid inter-crate conflicts two more measures are taken:
62//!
63//! - The name of the crate containing the symbol is prepended to the symbol
64//! name, i.e., symbols are "crate qualified". For example, a function `foo` in
65//! module `bar` in crate `baz` would get a symbol name like
66//! `baz::bar::foo::{hash}` instead of just `bar::foo::{hash}`. This avoids
67//! simple conflicts between functions from different crates.
68//!
69//! - In order to be able to also use symbols from two versions of the same
70//! crate (which naturally also have the same name), a stronger measure is
71//! required: The compiler accepts an arbitrary "disambiguator" value via the
72//! `-C metadata` command-line argument. This disambiguator is then fed into
73//! the symbol hash of every exported item. Consequently, the symbols in two
74//! identical crates but with different disambiguators are not in conflict
75//! with each other. This facility is mainly intended to be used by build
76//! tools like Cargo.
77//!
78//! A note on symbol name stability
79//! -------------------------------
80//! Previous versions of the compiler resorted to feeding NodeIds into the
81//! symbol hash in order to disambiguate between items with the same path. The
82//! current version of the name generation algorithm takes great care not to do
83//! that, since NodeIds are notoriously unstable: A small change to the
84//! code base will offset all NodeIds after the change and thus, much as using
85//! the SVH in the hash, invalidate an unbounded number of symbol names. This
86//! makes re-using previously compiled code for incremental compilation
87//! virtually impossible. Thus, symbol hash generation exclusively relies on
88//! DefPaths which are much more robust in the face of changes to the code base.
89
90use rustc_hir::def::DefKind;
91use rustc_hir::def_id::{CrateNum, LOCAL_CRATE};
92use rustc_middle::middle::codegen_fn_attrs::{CodegenFnAttrFlags, CodegenFnAttrs};
93use rustc_middle::mono::{InstantiationMode, MonoItem};
94use rustc_middle::query::Providers;
95use rustc_middle::ty::{self, Instance, InstanceKind, TyCtxt};
96use rustc_session::config::SymbolManglingVersion;
97use tracing::debug;
98
99mod export;
100mod hashed;
101mod legacy;
102mod v0;
103
104pub mod test;
105
106pub use v0::mangle_internal_symbol;
107
108/// This function computes the symbol name for the given `instance` and the
109/// given instantiating crate. That is, if you know that instance X is
110/// instantiated in crate Y, this is the symbol name this instance would have.
111pub fn symbol_name_for_instance_in_crate<'tcx>(
112 tcx: TyCtxt<'tcx>,
113 instance: Instance<'tcx>,
114 instantiating_crate: CrateNum,
115) -> String {
116 compute_symbol_name(tcx, instance, || instantiating_crate)
117}
118
119pub fn provide(providers: &mut Providers) {
120 *providers = Providers { symbol_name: symbol_name_provider, ..*providers };
121}
122
123// The `symbol_name` query provides the symbol name for calling a given
124// instance from the local crate. In particular, it will also look up the
125// correct symbol name of instances from upstream crates.
126fn symbol_name_provider<'tcx>(tcx: TyCtxt<'tcx>, instance: Instance<'tcx>) -> ty::SymbolName<'tcx> {
127 let symbol_name = compute_symbol_name(tcx, instance, || {
128 // This closure determines the instantiating crate for instances that
129 // need an instantiating-crate-suffix for their symbol name, in order
130 // to differentiate between local copies.
131 if is_generic(instance) {
132 // For generics we might find re-usable upstream instances. If there
133 // is one, we rely on the symbol being instantiated locally.
134 instance.upstream_monomorphization(tcx).unwrap_or(LOCAL_CRATE)
135 } else {
136 // For non-generic things that need to avoid naming conflicts, we
137 // always instantiate a copy in the local crate.
138 LOCAL_CRATE
139 }
140 });
141
142 ty::SymbolName::new(tcx, &symbol_name)
143}
144
145pub fn typeid_for_trait_ref<'tcx>(
146 tcx: TyCtxt<'tcx>,
147 trait_ref: ty::ExistentialTraitRef<'tcx>,
148) -> String {
149 v0::mangle_typeid_for_trait_ref(tcx, trait_ref)
150}
151
152pub fn symbol_name_from_attrs<'tcx>(
153 tcx: TyCtxt<'tcx>,
154 instance_kind: InstanceKind<'tcx>,
155) -> Option<String> {
156 let def_id = instance_kind.def_id();
157
158 if let Some(def_id) = def_id.as_local() {
159 if tcx.proc_macro_decls_static(()) == Some(def_id) {
160 let stable_crate_id = tcx.stable_crate_id(LOCAL_CRATE);
161 return Some(rustc_session::generate_proc_macro_decls_symbol(stable_crate_id));
162 }
163 }
164
165 // FIXME(eddyb) Precompute a custom symbol name based on attributes.
166 let attrs = if tcx.def_kind(def_id).has_codegen_attrs() {
167 &tcx.codegen_instance_attrs(instance_kind)
168 } else {
169 CodegenFnAttrs::EMPTY
170 };
171
172 if attrs.flags.contains(CodegenFnAttrFlags::RUSTC_STD_INTERNAL_SYMBOL) {
173 // Items marked as #[rustc_std_internal_symbol] need to have a fixed
174 // symbol name because it is used to import items from another crate
175 // without a direct dependency. As such it is not possible to look up
176 // the mangled name for the `Instance` from the crate metadata of the
177 // defining crate.
178 // Weak lang items automatically get #[rustc_std_internal_symbol]
179 // applied by the code computing the CodegenFnAttrs.
180 // We are mangling all #[rustc_std_internal_symbol] items as a
181 // combination of the rustc version and the unmangled linkage name.
182 // This is to ensure that if we link against a staticlib compiled by a
183 // different rustc version, we don't get symbol conflicts or even UB
184 // due to a different implementation/ABI. Rust staticlibs currently
185 // export all symbols, including those that are hidden in cdylibs.
186 // We are using the v0 symbol mangling scheme here as we need to be
187 // consistent across all crates and in some contexts the legacy symbol
188 // mangling scheme can't be used. For example both the GCC backend and
189 // Rust-for-Linux don't support some of the characters used by the
190 // legacy symbol mangling scheme.
191 let name = if let Some(name) = attrs.symbol_name { name } else { tcx.item_name(def_id) };
192
193 return Some(v0::mangle_internal_symbol(tcx, name.as_str()));
194 }
195
196 let wasm_import_module_exception_force_mangling = {
197 // * On the wasm32 targets there is a bug (or feature) in LLD [1] where the
198 // same-named symbol when imported from different wasm modules will get
199 // hooked up incorrectly. As a result foreign symbols, on the wasm target,
200 // with a wasm import module, get mangled. Additionally our codegen will
201 // deduplicate symbols based purely on the symbol name, but for wasm this
202 // isn't quite right because the same-named symbol on wasm can come from
203 // different modules. For these reasons if `#[link(wasm_import_module)]`
204 // is present we mangle everything on wasm because the demangled form will
205 // show up in the `wasm-import-name` custom attribute in LLVM IR.
206 //
207 // [1]: https://bugs.llvm.org/show_bug.cgi?id=44316
208 //
209 // So, on wasm if a foreign item loses its `#[no_mangle]`, it might *still*
210 // be mangled if we're forced to. Note: I don't like this.
211 // These kinds of exceptions should be added during the `codegen_attrs` query.
212 // However, we don't have the wasm import module map there yet.
213 tcx.is_foreign_item(def_id)
214 && tcx.sess.target.is_like_wasm
215 && tcx.wasm_import_module_map(def_id.krate).contains_key(&def_id)
216 };
217
218 if !wasm_import_module_exception_force_mangling {
219 if let Some(name) = attrs.symbol_name {
220 // Use provided name
221 return Some(name.to_string());
222 }
223
224 if attrs.flags.contains(CodegenFnAttrFlags::NO_MANGLE) {
225 // Don't mangle
226 return Some(tcx.item_name(def_id).to_string());
227 }
228 }
229
230 None
231}
232
233/// Computes the symbol name for the given instance. This function will call
234/// `compute_instantiating_crate` if it needs to factor the instantiating crate
235/// into the symbol name.
236fn compute_symbol_name<'tcx>(
237 tcx: TyCtxt<'tcx>,
238 instance: Instance<'tcx>,
239 compute_instantiating_crate: impl FnOnce() -> CrateNum,
240) -> String {
241 let def_id = instance.def_id();
242 let args = instance.args;
243
244 debug!("symbol_name(def_id={:?}, args={:?})", def_id, args);
245
246 if let Some(symbol) = symbol_name_from_attrs(tcx, instance.def) {
247 return symbol;
248 }
249
250 // If we're dealing with an instance of a function that's inlined from
251 // another crate but we're marking it as globally shared to our
252 // compilation (aka we're not making an internal copy in each of our
253 // codegen units) then this symbol may become an exported (but hidden
254 // visibility) symbol. This means that multiple crates may do the same
255 // and we want to be sure to avoid any symbol conflicts here.
256 let is_globally_shared_function = matches!(
257 tcx.def_kind(instance.def_id()),
258 DefKind::Fn
259 | DefKind::AssocFn
260 | DefKind::Closure
261 | DefKind::SyntheticCoroutineBody
262 | DefKind::Ctor(..)
263 ) && matches!(
264 MonoItem::Fn(instance).instantiation_mode(tcx),
265 InstantiationMode::GloballyShared { may_conflict: true }
266 );
267
268 // If this is an instance of a generic function, we also hash in
269 // the ID of the instantiating crate. This avoids symbol conflicts
270 // in case the same instances is emitted in two crates of the same
271 // project.
272 let avoid_cross_crate_conflicts = is_generic(instance) || is_globally_shared_function;
273
274 let instantiating_crate = avoid_cross_crate_conflicts.then(compute_instantiating_crate);
275
276 // Pick the crate responsible for the symbol mangling version, which has to:
277 // 1. be stable for each instance, whether it's being defined or imported
278 // 2. obey each crate's own `-C symbol-mangling-version`, as much as possible
279 // We solve these as follows:
280 // 1. because symbol names depend on both `def_id` and `instantiating_crate`,
281 // both their `CrateNum`s are stable for any given instance, so we can pick
282 // either and have a stable choice of symbol mangling version
283 // 2. we favor `instantiating_crate` where possible (i.e. when `Some`)
284 let mangling_version_crate = instantiating_crate.unwrap_or(def_id.krate);
285 let mangling_version = if mangling_version_crate == LOCAL_CRATE {
286 tcx.sess.opts.get_symbol_mangling_version()
287 } else {
288 tcx.symbol_mangling_version(mangling_version_crate)
289 };
290
291 let symbol = match tcx.is_exportable(def_id) {
292 true => format!(
293 "{}.{}",
294 v0::mangle(tcx, instance, instantiating_crate, true),
295 export::compute_hash_of_export_fn(tcx, instance)
296 ),
297 false => match mangling_version {
298 SymbolManglingVersion::Legacy => {
299 let mangled_name = legacy::mangle(tcx, instance, instantiating_crate);
300
301 let mangled_name_too_long = {
302 // The PDB debug info format cannot store mangled symbol names for which its
303 // internal record exceeds u16::MAX bytes, a limit multiple Rust projects have been
304 // hitting due to the verbosity of legacy name mangling. Depending on the linker version
305 // in use, such symbol names can lead to linker crashes or incomprehensible linker error
306 // about a limit being hit.
307 // Mangle those symbols with v0 mangling instead, which gives us more room to breathe
308 // as v0 mangling is more compact.
309 // Empirical testing has shown the limit for the symbol name to be 65521 bytes; use
310 // 65000 bytes to leave some room for prefixes / suffixes as well as unknown scenarios
311 // with a different limit.
312 const MAX_SYMBOL_LENGTH: usize = 65000;
313
314 tcx.sess.target.uses_pdb_debuginfo() && mangled_name.len() > MAX_SYMBOL_LENGTH
315 };
316
317 if mangled_name_too_long {
318 v0::mangle(tcx, instance, instantiating_crate, false)
319 } else {
320 mangled_name
321 }
322 }
323 SymbolManglingVersion::V0 => v0::mangle(tcx, instance, instantiating_crate, false),
324 SymbolManglingVersion::Hashed => {
325 hashed::mangle(tcx, instance, instantiating_crate, || {
326 v0::mangle(tcx, instance, instantiating_crate, false)
327 })
328 }
329 },
330 };
331
332 debug_assert!(
333 rustc_demangle::try_demangle(&symbol).is_ok(),
334 "compute_symbol_name: `{symbol}` cannot be demangled"
335 );
336
337 symbol
338}
339
340fn is_generic<'tcx>(instance: Instance<'tcx>) -> bool {
341 instance.args.non_erasable_generics().next().is_some()
342}