Native Interface (super issue)
Created by: wks
This is an outline of issues related to the native interface, that is, interacting with the native world. This topic includes but is not limited to object layout, pointer types, object pinning and foreign function calls. We should open other issues to discuss concrete problems.
- Make a platform-specific Mu specification
- Address some of the following issues, including object layout, calling convention, ...
- Draft for AMD64: https://github.com/microvm/microvm-spec/wiki/native-interface-x64-unix
- Type system: (https://github.com/microvm/microvm-meta/issues/34)
- Raw pointer types
- Structure types with native/explicit object layout
- Union types (unlikely to have in Mu)
- Mapping Mu types to C types and native object layout: (in the Native Interface chapter in the spec)
- Memory space beyond heap/stack/global
- Memory spaces with various constraints
- Is it movable, pinnable, has reference, can be referenced to, GC-traced, GC-collected, ...?
- Object pinning: https://github.com/microvm/microvm-meta/issues/28
- If object pinning is allowed, what does "pin" mean?
- Memory spaces with various constraints
- Foreign function interfaces
- Calling foreign functions from Mu: (The CCALL instruction. See the spec)
- Calling C functions
- System calls
- Calling back to Mu from foreign functions: https://github.com/microvm/microvm-meta/issues/39
- From C functions
- Signal handling
- Calling foreign functions from Mu: (The CCALL instruction. See the spec)
The following should be addressed by a higher-level abstraction:
- Loading native libraries
- The client loads libc and finds the address of
dlopen
,dlsym
,dlclose
anddlerror
. Then theCCALL
instruction takes care of the rest by calling them.
- The client loads libc and finds the address of
- Loading "heavier-weight" Mu bundles (currently called MuLF): https://github.com/microvm/microvm-meta/issues/30
The following are not related to the native interface, but are related to raw memory:
- How to expose the address of objects so that the user can analyse the memory behaviour? (This involves profiling, too. We may open a dedicated issue for profiling.)