wasmtime_cranelift_shared/obj.rs
1//! Object file builder.
2//!
3//! Creates ELF image based on `Compilation` information. The ELF contains
4//! functions and trampolines in the ".text" section. It also contains all
5//! relocation records for the linking stage. If DWARF sections exist, their
6//! content will be written as well.
7//!
8//! The object file has symbols for each function and trampoline, as well as
9//! symbols that refer to libcalls.
10//!
11//! The function symbol names have format "_wasm_function_N", where N is
12//! `FuncIndex`. The defined wasm function symbols refer to a JIT compiled
13//! function body, the imported wasm function do not. The trampolines symbol
14//! names have format "_trampoline_N", where N is `SignatureIndex`.
15
16use crate::{Relocation, RelocationTarget};
17use anyhow::Result;
18use cranelift_codegen::binemit::Reloc;
19use cranelift_codegen::ir::LibCall;
20use cranelift_codegen::isa::unwind::{systemv, UnwindInfo};
21use cranelift_codegen::TextSectionBuilder;
22use gimli::write::{Address, EhFrame, EndianVec, FrameTable, Writer};
23use gimli::RunTimeEndian;
24use object::write::{Object, SectionId, StandardSegment, Symbol, SymbolId, SymbolSection};
25use object::{Architecture, SectionKind, SymbolFlags, SymbolKind, SymbolScope};
26use std::collections::HashMap;
27use std::convert::TryFrom;
28use std::ops::Range;
29use wasmtime_environ::{Compiler, FuncIndex};
30
31const TEXT_SECTION_NAME: &[u8] = b".text";
32
33/// A helper structure used to assemble the final text section of an exectuable,
34/// plus unwinding information and other related details.
35///
36/// This builder relies on Cranelift-specific internals but assembles into a
37/// generic `Object` which will get further appended to in a compiler-agnostic
38/// fashion later.
39pub struct ModuleTextBuilder<'a> {
40 /// The target that we're compiling for, used to query target-specific
41 /// information as necessary.
42 compiler: &'a dyn Compiler,
43
44 /// The object file that we're generating code into.
45 obj: &'a mut Object<'static>,
46
47 /// The WebAssembly module we're generating code for.
48 text_section: SectionId,
49
50 unwind_info: UnwindInfoBuilder<'a>,
51
52 /// In-progress text section that we're using cranelift's `MachBuffer` to
53 /// build to resolve relocations (calls) between functions.
54 text: Box<dyn TextSectionBuilder>,
55
56 /// Symbols defined in the object for libcalls that relocations are applied
57 /// against.
58 ///
59 /// Note that this isn't typically used. It's only used for SSE-disabled
60 /// builds without SIMD on x86_64 right now.
61 libcall_symbols: HashMap<LibCall, SymbolId>,
62}
63
64impl<'a> ModuleTextBuilder<'a> {
65 /// Creates a new builder for the text section of an executable.
66 ///
67 /// The `.text` section will be appended to the specified `obj` along with
68 /// any unwinding or such information as necessary. The `num_funcs`
69 /// parameter indicates the number of times the `append_func` function will
70 /// be called. The `finish` function will panic if this contract is not met.
71 pub fn new(
72 obj: &'a mut Object<'static>,
73 compiler: &'a dyn Compiler,
74 text: Box<dyn TextSectionBuilder>,
75 ) -> Self {
76 // Entire code (functions and trampolines) will be placed
77 // in the ".text" section.
78 let text_section = obj.add_section(
79 obj.segment_name(StandardSegment::Text).to_vec(),
80 TEXT_SECTION_NAME.to_vec(),
81 SectionKind::Text,
82 );
83
84 Self {
85 compiler,
86 obj,
87 text_section,
88 unwind_info: Default::default(),
89 text,
90 libcall_symbols: HashMap::default(),
91 }
92 }
93
94 /// Appends the `func` specified named `name` to this object.
95 ///
96 /// The `resolve_reloc_target` closure is used to resolve a relocation
97 /// target to an adjacent function which has already been added or will be
98 /// added to this object. The argument is the relocation target specified
99 /// within `CompiledFunction` and the return value must be an index where
100 /// the target will be defined by the `n`th call to `append_func`.
101 ///
102 /// Returns the symbol associated with the function as well as the range
103 /// that the function resides within the text section.
104 pub fn append_func(
105 &mut self,
106 name: &str,
107 body: &[u8],
108 alignment: u32,
109 unwind_info: Option<&'a UnwindInfo>,
110 relocations: &[Relocation],
111 resolve_reloc_target: impl Fn(FuncIndex) -> usize,
112 ) -> (SymbolId, Range<u64>) {
113 let body_len = body.len() as u64;
114 let off = self.text.append(
115 true,
116 &body,
117 self.compiler.function_alignment().max(alignment),
118 );
119
120 let symbol_id = self.obj.add_symbol(Symbol {
121 name: name.as_bytes().to_vec(),
122 value: off,
123 size: body_len,
124 kind: SymbolKind::Text,
125 scope: SymbolScope::Compilation,
126 weak: false,
127 section: SymbolSection::Section(self.text_section),
128 flags: SymbolFlags::None,
129 });
130
131 if let Some(info) = unwind_info {
132 self.unwind_info.push(off, body_len, info);
133 }
134
135 for r in relocations {
136 match r.reloc_target {
137 // Relocations against user-defined functions means that this is
138 // a relocation against a module-local function, typically a
139 // call between functions. The `text` field is given priority to
140 // resolve this relocation before we actually emit an object
141 // file, but if it can't handle it then we pass through the
142 // relocation.
143 RelocationTarget::UserFunc(index) => {
144 let target = resolve_reloc_target(index);
145 if self
146 .text
147 .resolve_reloc(off + u64::from(r.offset), r.reloc, r.addend, target)
148 {
149 continue;
150 }
151
152 // At this time it's expected that all relocations are
153 // handled by `text.resolve_reloc`, and anything that isn't
154 // handled is a bug in `text.resolve_reloc` or something
155 // transitively there. If truly necessary, though, then this
156 // loop could also be updated to forward the relocation to
157 // the final object file as well.
158 panic!(
159 "unresolved relocation could not be procesed against \
160 {index:?}: {r:?}"
161 );
162 }
163
164 // Relocations against libcalls are not common at this time and
165 // are only used in non-default configurations that disable wasm
166 // SIMD, disable SSE features, and for wasm modules that still
167 // use floating point operations.
168 //
169 // Currently these relocations are all expected to be absolute
170 // 8-byte relocations so that's asserted here and then encoded
171 // directly into the object as a normal object relocation. This
172 // is processed at module load time to resolve the relocations.
173 RelocationTarget::LibCall(call) => {
174 let symbol = *self.libcall_symbols.entry(call).or_insert_with(|| {
175 self.obj.add_symbol(Symbol {
176 name: libcall_name(call).as_bytes().to_vec(),
177 value: 0,
178 size: 0,
179 kind: SymbolKind::Text,
180 scope: SymbolScope::Linkage,
181 weak: false,
182 section: SymbolSection::Undefined,
183 flags: SymbolFlags::None,
184 })
185 });
186 let (encoding, kind, size) = match r.reloc {
187 Reloc::Abs8 => (
188 object::RelocationEncoding::Generic,
189 object::RelocationKind::Absolute,
190 8,
191 ),
192 other => unimplemented!("unimplemented relocation kind {other:?}"),
193 };
194 self.obj
195 .add_relocation(
196 self.text_section,
197 object::write::Relocation {
198 symbol,
199 size,
200 kind,
201 encoding,
202 offset: off + u64::from(r.offset),
203 addend: r.addend,
204 },
205 )
206 .unwrap();
207 }
208 };
209 }
210 (symbol_id, off..off + body_len)
211 }
212
213 /// Forces "veneers" to be used for inter-function calls in the text
214 /// section which means that in-bounds optimized addresses are never used.
215 ///
216 /// This is only useful for debugging cranelift itself and typically this
217 /// option is disabled.
218 pub fn force_veneers(&mut self) {
219 self.text.force_veneers();
220 }
221
222 /// Appends the specified amount of bytes of padding into the text section.
223 ///
224 /// This is only useful when fuzzing and/or debugging cranelift itself and
225 /// for production scenarios `padding` is 0 and this function does nothing.
226 pub fn append_padding(&mut self, padding: usize) {
227 if padding == 0 {
228 return;
229 }
230 self.text.append(false, &vec![0; padding], 1);
231 }
232
233 /// Indicates that the text section has been written completely and this
234 /// will finish appending it to the original object.
235 ///
236 /// Note that this will also write out the unwind information sections if
237 /// necessary.
238 pub fn finish(mut self) {
239 // Finish up the text section now that we're done adding functions.
240 let text = self.text.finish();
241 self.obj
242 .section_mut(self.text_section)
243 .set_data(text, self.compiler.page_size_align());
244
245 // Append the unwind information for all our functions, if necessary.
246 self.unwind_info
247 .append_section(self.compiler, self.obj, self.text_section);
248 }
249}
250
251/// Builder used to create unwind information for a set of functions added to a
252/// text section.
253#[derive(Default)]
254struct UnwindInfoBuilder<'a> {
255 windows_xdata: Vec<u8>,
256 windows_pdata: Vec<RUNTIME_FUNCTION>,
257 systemv_unwind_info: Vec<(u64, &'a systemv::UnwindInfo)>,
258}
259
260// This is a mirror of `RUNTIME_FUNCTION` in the Windows API, but defined here
261// to ensure everything is always `u32` and to have it available on all
262// platforms. Note that all of these specifiers here are relative to a "base
263// address" which we define as the base of where the text section is eventually
264// loaded.
265#[allow(non_camel_case_types)]
266struct RUNTIME_FUNCTION {
267 begin: u32,
268 end: u32,
269 unwind_address: u32,
270}
271
272impl<'a> UnwindInfoBuilder<'a> {
273 /// Pushes the unwind information for a function into this builder.
274 ///
275 /// The function being described must be located at `function_offset` within
276 /// the text section itself, and the function's size is specified by
277 /// `function_len`.
278 ///
279 /// The `info` should come from Cranelift. and is handled here depending on
280 /// its flavor.
281 fn push(&mut self, function_offset: u64, function_len: u64, info: &'a UnwindInfo) {
282 match info {
283 // Windows unwind information is stored in two locations:
284 //
285 // * First is the actual unwinding information which is stored
286 // in the `.xdata` section. This is where `info`'s emitted
287 // information will go into.
288 // * Second are pointers to connect all this unwind information,
289 // stored in the `.pdata` section. The `.pdata` section is an
290 // array of `RUNTIME_FUNCTION` structures.
291 //
292 // Due to how these will be loaded at runtime the `.pdata` isn't
293 // actually assembled byte-wise here. Instead that's deferred to
294 // happen later during `write_windows_unwind_info` which will apply
295 // a further offset to `unwind_address`.
296 UnwindInfo::WindowsX64(info) => {
297 let unwind_size = info.emit_size();
298 let mut unwind_info = vec![0; unwind_size];
299 info.emit(&mut unwind_info);
300
301 // `.xdata` entries are always 4-byte aligned
302 //
303 // FIXME: in theory we could "intern" the `unwind_info` value
304 // here within the `.xdata` section. Most of our unwind
305 // information for functions is probably pretty similar in which
306 // case the `.xdata` could be quite small and `.pdata` could
307 // have multiple functions point to the same unwinding
308 // information.
309 while self.windows_xdata.len() % 4 != 0 {
310 self.windows_xdata.push(0x00);
311 }
312 let unwind_address = self.windows_xdata.len();
313 self.windows_xdata.extend_from_slice(&unwind_info);
314
315 // Record a `RUNTIME_FUNCTION` which this will point to.
316 self.windows_pdata.push(RUNTIME_FUNCTION {
317 begin: u32::try_from(function_offset).unwrap(),
318 end: u32::try_from(function_offset + function_len).unwrap(),
319 unwind_address: u32::try_from(unwind_address).unwrap(),
320 });
321 }
322
323 // System-V is different enough that we just record the unwinding
324 // information to get processed at a later time.
325 UnwindInfo::SystemV(info) => {
326 self.systemv_unwind_info.push((function_offset, info));
327 }
328
329 _ => panic!("some unwind info isn't handled here"),
330 }
331 }
332
333 /// Appends the unwind information section, if any, to the `obj` specified.
334 ///
335 /// This function must be called immediately after the text section was
336 /// added to a builder. The unwind information section must trail the text
337 /// section immediately.
338 ///
339 /// The `text_section`'s section identifier is passed into this function.
340 fn append_section(
341 &self,
342 compiler: &dyn Compiler,
343 obj: &mut Object<'_>,
344 text_section: SectionId,
345 ) {
346 // This write will align the text section to a page boundary and then
347 // return the offset at that point. This gives us the full size of the
348 // text section at that point, after alignment.
349 let text_section_size =
350 obj.append_section_data(text_section, &[], compiler.page_size_align());
351
352 if self.windows_xdata.len() > 0 {
353 assert!(self.systemv_unwind_info.len() == 0);
354 // The `.xdata` section must come first to be just-after the `.text`
355 // section for the reasons documented in `write_windows_unwind_info`
356 // below.
357 let segment = obj.segment_name(StandardSegment::Data).to_vec();
358 let xdata_id = obj.add_section(segment, b".xdata".to_vec(), SectionKind::ReadOnlyData);
359 let segment = obj.segment_name(StandardSegment::Data).to_vec();
360 let pdata_id = obj.add_section(segment, b".pdata".to_vec(), SectionKind::ReadOnlyData);
361 self.write_windows_unwind_info(obj, xdata_id, pdata_id, text_section_size);
362 }
363
364 if self.systemv_unwind_info.len() > 0 {
365 let segment = obj.segment_name(StandardSegment::Data).to_vec();
366 let section_id =
367 obj.add_section(segment, b".eh_frame".to_vec(), SectionKind::ReadOnlyData);
368 self.write_systemv_unwind_info(compiler, obj, section_id, text_section_size)
369 }
370 }
371
372 /// This function appends a nonstandard section to the object which is only
373 /// used during `CodeMemory::publish`.
374 ///
375 /// This custom section effectively stores a `[RUNTIME_FUNCTION; N]` into
376 /// the object file itself. This way registration of unwind info can simply
377 /// pass this slice to the OS itself and there's no need to recalculate
378 /// anything on the other end of loading a module from a precompiled object.
379 ///
380 /// Support for reading this is in `crates/jit/src/unwind/winx64.rs`.
381 fn write_windows_unwind_info(
382 &self,
383 obj: &mut Object<'_>,
384 xdata_id: SectionId,
385 pdata_id: SectionId,
386 text_section_size: u64,
387 ) {
388 // Currently the binary format supported here only supports
389 // little-endian for x86_64, or at least that's all where it's tested.
390 // This may need updates for other platforms.
391 assert_eq!(obj.architecture(), Architecture::X86_64);
392
393 // Append the `.xdata` section, or the actual unwinding information
394 // codes and such which were built as we found unwind information for
395 // functions.
396 obj.append_section_data(xdata_id, &self.windows_xdata, 4);
397
398 // Next append the `.pdata` section, or the array of `RUNTIME_FUNCTION`
399 // structures stored in the binary.
400 //
401 // This memory will be passed at runtime to `RtlAddFunctionTable` which
402 // takes a "base address" and the entries within `RUNTIME_FUNCTION` are
403 // all relative to this base address. The base address we pass is the
404 // address of the text section itself so all the pointers here must be
405 // text-section-relative. The `begin` and `end` fields for the function
406 // it describes are already text-section-relative, but the
407 // `unwind_address` field needs to be updated here since the value
408 // stored right now is `xdata`-section-relative. We know that the
409 // `xdata` section follows the `.text` section so the
410 // `text_section_size` is added in to calculate the final
411 // `.text`-section-relative address of the unwind information.
412 let mut pdata = Vec::with_capacity(self.windows_pdata.len() * 3 * 4);
413 for info in self.windows_pdata.iter() {
414 pdata.extend_from_slice(&info.begin.to_le_bytes());
415 pdata.extend_from_slice(&info.end.to_le_bytes());
416 let address = text_section_size + u64::from(info.unwind_address);
417 let address = u32::try_from(address).unwrap();
418 pdata.extend_from_slice(&address.to_le_bytes());
419 }
420 obj.append_section_data(pdata_id, &pdata, 4);
421 }
422
423 /// This function appends a nonstandard section to the object which is only
424 /// used during `CodeMemory::publish`.
425 ///
426 /// This will generate a `.eh_frame` section, but not one that can be
427 /// naively loaded. The goal of this section is that we can create the
428 /// section once here and never again does it need to change. To describe
429 /// dynamically loaded functions though each individual FDE needs to talk
430 /// about the function's absolute address that it's referencing. Naturally
431 /// we don't actually know the function's absolute address when we're
432 /// creating an object here.
433 ///
434 /// To solve this problem the FDE address encoding mode is set to
435 /// `DW_EH_PE_pcrel`. This means that the actual effective address that the
436 /// FDE describes is a relative to the address of the FDE itself. By
437 /// leveraging this relative-ness we can assume that the relative distance
438 /// between the FDE and the function it describes is constant, which should
439 /// allow us to generate an FDE ahead-of-time here.
440 ///
441 /// For now this assumes that all the code of functions will start at a
442 /// page-aligned address when loaded into memory. The eh_frame encoded here
443 /// then assumes that the text section is itself page aligned to its size
444 /// and the eh_frame will follow just after the text section. This means
445 /// that the relative offsets we're using here is the FDE going backwards
446 /// into the text section itself.
447 ///
448 /// Note that the library we're using to create the FDEs, `gimli`, doesn't
449 /// actually encode addresses relative to the FDE itself. Instead the
450 /// addresses are encoded relative to the start of the `.eh_frame` section.
451 /// This makes it much easier for us where we provide the relative offset
452 /// from the start of `.eh_frame` to the function in the text section, which
453 /// given our layout basically means the offset of the function in the text
454 /// section from the end of the text section.
455 ///
456 /// A final note is that the reason we page-align the text section's size is
457 /// so the .eh_frame lives on a separate page from the text section itself.
458 /// This allows `.eh_frame` to have different virtual memory permissions,
459 /// such as being purely read-only instead of read/execute like the code
460 /// bits.
461 fn write_systemv_unwind_info(
462 &self,
463 compiler: &dyn Compiler,
464 obj: &mut Object<'_>,
465 section_id: SectionId,
466 text_section_size: u64,
467 ) {
468 let mut cie = compiler
469 .create_systemv_cie()
470 .expect("must be able to create a CIE for system-v unwind info");
471 let mut table = FrameTable::default();
472 cie.fde_address_encoding = gimli::constants::DW_EH_PE_pcrel;
473 let cie_id = table.add_cie(cie);
474
475 for (text_section_off, unwind_info) in self.systemv_unwind_info.iter() {
476 let backwards_off = text_section_size - text_section_off;
477 let actual_offset = -i64::try_from(backwards_off).unwrap();
478 // Note that gimli wants an unsigned 64-bit integer here, but
479 // unwinders just use this constant for a relative addition with the
480 // address of the FDE, which means that the sign doesn't actually
481 // matter.
482 let fde = unwind_info.to_fde(Address::Constant(actual_offset as u64));
483 table.add_fde(cie_id, fde);
484 }
485 let endian = match compiler.triple().endianness().unwrap() {
486 target_lexicon::Endianness::Little => RunTimeEndian::Little,
487 target_lexicon::Endianness::Big => RunTimeEndian::Big,
488 };
489 let mut eh_frame = EhFrame(MyVec(EndianVec::new(endian)));
490 table.write_eh_frame(&mut eh_frame).unwrap();
491
492 // Some unwinding implementations expect a terminating "empty" length so
493 // a 0 is written at the end of the table for those implementations.
494 let mut endian_vec = (eh_frame.0).0;
495 endian_vec.write_u32(0).unwrap();
496 obj.append_section_data(section_id, endian_vec.slice(), 1);
497
498 use gimli::constants;
499 use gimli::write::Error;
500
501 struct MyVec(EndianVec<RunTimeEndian>);
502
503 impl Writer for MyVec {
504 type Endian = RunTimeEndian;
505
506 fn endian(&self) -> RunTimeEndian {
507 self.0.endian()
508 }
509
510 fn len(&self) -> usize {
511 self.0.len()
512 }
513
514 fn write(&mut self, buf: &[u8]) -> Result<(), Error> {
515 self.0.write(buf)
516 }
517
518 fn write_at(&mut self, pos: usize, buf: &[u8]) -> Result<(), Error> {
519 self.0.write_at(pos, buf)
520 }
521
522 // FIXME(gimli-rs/gimli#576) this is the definition we want for
523 // `write_eh_pointer` but the default implementation, at the time
524 // of this writing, uses `offset - val` instead of `val - offset`.
525 // A PR has been merged to fix this but until that's published we
526 // can't use it.
527 fn write_eh_pointer(
528 &mut self,
529 address: Address,
530 eh_pe: constants::DwEhPe,
531 size: u8,
532 ) -> Result<(), Error> {
533 let val = match address {
534 Address::Constant(val) => val,
535 Address::Symbol { .. } => unreachable!(),
536 };
537 assert_eq!(eh_pe.application(), constants::DW_EH_PE_pcrel);
538 let offset = self.len() as u64;
539 let val = val.wrapping_sub(offset);
540 self.write_eh_pointer_data(val, eh_pe.format(), size)
541 }
542 }
543 }
544}
545
546fn libcall_name(call: LibCall) -> &'static str {
547 use wasmtime_environ::obj::LibCall as LC;
548 let other = match call {
549 LibCall::FloorF32 => LC::FloorF32,
550 LibCall::FloorF64 => LC::FloorF64,
551 LibCall::NearestF32 => LC::NearestF32,
552 LibCall::NearestF64 => LC::NearestF64,
553 LibCall::CeilF32 => LC::CeilF32,
554 LibCall::CeilF64 => LC::CeilF64,
555 LibCall::TruncF32 => LC::TruncF32,
556 LibCall::TruncF64 => LC::TruncF64,
557 LibCall::FmaF32 => LC::FmaF32,
558 LibCall::FmaF64 => LC::FmaF64,
559 _ => panic!("unknown libcall to give a name to: {call:?}"),
560 };
561 other.symbol()
562}