387426e7f4
* cranelift: improve syscall error/oom handling in JIT module The JIT module has several places where it `expect`s or `panic`s on syscall or allocator errors. For example, `mmap` and `mprotect` can fail if Linux `vm.max_map_count` is not high enough, and some users may wish to handle this error rather than immediately crashing. This commit plumbs these errors upward as new `ModuleError` types, so that callers of jit module functions like `finalize_definitions` and `define_function` can handle them (or just `unwrap()`, as desired). * cranelift: Remove ModuleError::Syscall variant Syscall errors can just be folded into the generic Backend error, which is an anyhow::Error * cranelift-jit: return io::ErrorKind::OutOfMemory for alloc failure Just using `io::Error::last_os_error()` is not correct as global allocator impls are not required to set errno
This crate provides module-level functionality, which allow multiple functions and data to be emitted with Cranelift and then linked together.
This crate is structured as an optional layer on top of cranelift-codegen. It provides additional functionality, such as linking, however users that require greater flexibility don't need to use it.
A module is a collection of functions and data objects that are linked
together. The Module trait that defines a common interface for various kinds
of modules. Most users will use one of the following Module implementations:
JITModule, provided by cranelift-jit, which JITs code to memory for direct execution.ObjectModule, provided by cranelift-object, which emits native object files.