A colleague recently came across the interaction between
-finstrument-functions and inline functions mentioned here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23296
As the bug submitter says, the problem is that for something like:
#include <stdio.h>
void g (void) { printf("Here\n"); }
int main (void) { g (); return 0; }
compiled with "-O3 -finstrument-functions", you get two successive calls
to __cyg_profile_func_enter _with the same arguments_. That is, both
calls say that they are entering main():
...
__cyg_profile_func_enter (&main, <return-addr>);
...
__cyg_profile_func_enter (&main, <return-addr>);
...
__cyg_profile_func_exit (&main, <return-addr>);
...
__cyg_profile_func_exit (&main, <return-addr>);
...
Is this really the intended behaviour? Andrew closed the bug as invalid,
saying that this is what we expect, but the docs seem to suggest that we
ought to do something like:
...
__cyg_profile_func_enter (&main, ...);
...
__cyg_profile_func_enter (&g, ...);
...
__cyg_profile_func_exit (&g, ...);
...
__cyg_profile_func_exit (&main, ...);
...
instead. [I'm going off:
This instrumentation is also done for functions expanded inline in other
functions. The profiling calls will indicate where, conceptually, the
inline function is entered and exited. This means that addressable
versions of such functions must be available. If all your uses of a
function are expanded inline, this may mean an additional expansion of
code size. If you use @samp{extern inline} in your C code, an
addressable version of such functions must be provided. (This is
normally the case anyways, but if you get lucky and the optimizer always
expands the functions inline, you might have gotten away without
providing static copies.)
Although it doesn't explicitly say _why_ we need addressable versions,
the context suggests to me that we're supposed to be passing them
as the "this_fn" argument to the hooks.]
Richard
