blob: 3f3e84b3182db013220aed90ec04831fecdc43d9 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
Multi-ABI support
=================
It would be nice to be able to support multiple ABI's in the (future)
language ecosystem, e.g. transitioning away smoothly from a broken ABI
or if a supported architecture changes its ABI.
There are several ways to do this:
1. Include ABI in symbol hash. This works with existing executable formats
(as long as the system doesn't embed the ABI in the executable headers
or in the filename).
2. Build a shim module for the old ABI. This should work with practically
any system, but will lead to multiple outputs (which complicates things;
e.g. what should the `-o` option do? do "surrounding" tools support it?)
3. Have the loader generate thunks at load-time if needed. But this requires
emitting executable code and then remapping it as executable. Some systems
might not support that.
These are limited to supporting calling convention changes only. Data
layout changes cannot be handled (I think?) by these methods.
Function pointers would need special handling also. Maybe function pointers
could be an opaque structure, that is generated and calling via the runtime?
These could have to be exposed to the C API also. Maybe as a macro, so it
can be #ifdef'ed to the correct definition at compile-time.
|
