blob: 3c877728898e0813893061dbb290a5a3828e24c4 (
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
|
OS function names
=================
There are some functions that SLUL probably shouldn't provide,
such as those in libm on POSIX systems:
double sin(double x);
float sinf(float x);
...
But we still want to have slul-friendly names of those:
func .sin(float x) -> float
func .sin(float32 x) -> float32
...
Also, we don't want to have any system-specific stuff in the
interface files! And some systems might not even need any special
handling for these functions.
But, normally, the names of these would then be:
(TODO reserve Float/Int/etc. as type names)
Float_sin
Float32_sin
Solution 1: Have a system-installed mapping file
------------------------------------------------
E.g. /usr/share/slul/system/elf_posix.mapping:
Float_sin acb123def456ghj789... sin
Float32_sin 987zyx654wvu321tsr... sinf
^-- from name ^-- funcdef hash ^-- to name
Perhaps this should be per "userabi" instead, and use the multi-arch triple:
/usr/share/slul/system/userabi_gnu.mapping
/usr/share/slul/system/userabi_musl.mapping
Solution 2: Hard-code these in the compiler
-------------------------------------------
This means that they can't be overridden without a re-compilation.
Problems (with both solutions)
------------------------------
If new ones are added to the interface file without adding them to
the mapping, then they will be compiled with the wrong name (and
generate a load-time error).
Another issue is that binaries become locked to a specific
user-ABI/system/libc. This includes modules of library type also!
|
