Closed lks9 closed 4 months ago
We can open a new issue when there is hope to detect function access through pointers. Otherwise, there is no way to solve the first two. Task 3 (small functions) is too vague anyways.
I have a new approach which makes nasty use of the C pre processor:
Suppose we have a function with the following signature:
int foo(int x);
Replace it in the instrumentation with:
#undef foo
int foo(int x);
#define foo(...) foo_orig(__VA_ARGS__)
int foo(int x);
And the body:
int foo(int x) {
CODE
}
Replace with:
int foo_orig(int x) {
INSTRUMENTED_CODE
}
#undef foo
int foo(int x) { __FUNC(num)
return foo_orig(x);
}
#define foo(...) foo_orig(__VA_ARGS__)
This way, a call to foo_orig()
won't cause the function to be reported with __FUNC(num)
. Test:
foo(1);
int (*f)(int) = foo;
f(2);
(*foo)(2);
Only foo(1)
is replaced with foo_orig(1)
by the pre processor. foo(1)
does not output the function number while f(2)
and (*foo)(3)
do. This is as it should be because the first is called by function name (hence without _FUNC(num)
reconstructable) whereas the others are called by pointer.
Well, but the problem is: How to decide on which function calls to skip?
function_pointer_only
)Small Functions which are often (and recursively) called as long as the trace keeps being reconstructable?--inline
to instrument them anyway).--anon
to instrument all functions anonymously.--no-functions
and--no-returns
.The problem is that we would need some static analysis to detect the first three.