You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Analyzed programs often call functions for which the implementation is not available to Goblint.
4
+
These can belong to the standard libraries of C, POSIX, Linux kernel, etc or to project dependencies whose implementation is not available.
5
+
6
+
Goblint outputs "Function definition missing" errors in such cases and by default assumes the worst about what the function does (invalidating everything).
7
+
Such invalidation is a major source of imprecision and should be avoided at all cost (while still being sound).
8
+
The semantics of unknown functions are controlled by options under `sem.unknown_function`, which can be used to avoid the invalidation, but disabling them if any unknown function does such invalidation will lead to unsoundness.
9
+
10
+
To strike a better balance between soundness and precision, more fine-grained specifications can be provided in the `LibraryFunctions` module.
11
+
12
+
13
+
## Library function specifications
14
+
15
+
In the `LibraryFunctions` module (implementation), specifications of library functions are organized into a number of association lists.
16
+
Functions are grouped based on their origin and context.
17
+
This (in the future[^spec-list-selection]) allows groups of library function specifications to be toggled based on the program under analysis.
18
+
19
+
There are also older (less granular) specifications implemented using `classify` and `invalidate_actions`.
20
+
No new specifications should be added there and all the existing ones should be migrated to the new DSL-based format.
21
+
22
+
[^spec-list-selection]: Specification list toggling will only be possible when all the old specifications are migrated.
23
+
24
+
25
+
## Library function descriptor DSL
26
+
27
+
A library function's specification is a pair of its name and descriptor (of type `LibraryDesc.t`).
28
+
The descriptors are easiest written using the OCaml DSL from `LibraryDsl`.
29
+
30
+
31
+
### Function descriptor
32
+
33
+
A function descriptor can be one of the following:
34
+
35
+
1.`special` consists of an arguments descriptor and a continuation function for converting the captured arguments to a `LibraryDesc.special` variant.
36
+
This is used when the library function should (or at least could) be specially handled by analyses.
37
+
38
+
2.`unknown` consists of just an arguments descriptor (which must `drop` all arguments) and defaults to `Unknown` variant.
39
+
This is used when the library function isn't specially handled by analyses.
40
+
41
+
42
+
### Arguments descriptor
43
+
44
+
An arguments descriptor is a list (with standard OCaml list syntax) of individual argument descriptors.
45
+
Additionally for library functions with variadic arguments, the list may be terminated with `VarArg` constructor instead of `[]`.
46
+
47
+
48
+
### Argument descriptor
49
+
50
+
An argument descriptor can be one of the following:
51
+
52
+
1.`__` captures the argument expression for use in `special`'s continuation function.
53
+
2.`drop` ignores (drops) the argument expression to not be used by the continuation.
54
+
55
+
Both functions consist of an argument name string (for readability purposes) and a list of accesses the function does to the _pointer_ argument.
56
+
57
+
Unnamed variants of the functions `__'` and `drop'` also exist, but should be avoided.
58
+
59
+
60
+
### Access
61
+
62
+
An access consists of an access kind and depth.
63
+
Access kinds (`AccessKind.t`) are: read, write, free and spawn.
64
+
65
+
Accesses specify what the library function may do with the corresponding _pointer_ argument.
66
+
Since function calls unconditionally read the immediate expressions given as arguments, there would be no point specifying that all the arguments (including of integer) type are read.
67
+
Also, non-pointer arguments are copied (passed-by-value) to the function, so write accesses would make no sense.
68
+
Therefore only pointer arguments should have accesses specified.
69
+
70
+
Two depths of accessing are distinguished:
71
+
72
+
1. Shallow (non-transitive, may-point-to) access means the function dereferences the pointer argument, but doesn't dereference any pointers within (e.g. if a pointer to struct is given as argument, but the struct contains further pointers).
73
+
This is is almost always the case for standard library functions, since they take `void*` or `char*` as generic memory arguments and don't know about any pointers within the pointed block of memory.
74
+
75
+
2. Deep (transitive, reachable) access means the function follows (dereferences) pointers within.
76
+
77
+
In the DSL, shallow accesses can be specified by `r`, `w`, `f` or `s`, respectively. Deep accesses can be specified using the previous values with an additional `_deep` suffix.
0 commit comments