-finstrument-functions and inlining problems (again)

["Ioannis E. Venetis" <iev at hpclab dot ceid dot upatras dot gr>]

Hello,

A long time ago, I sent a message to the list
(http://gcc.gnu.org/ml/gcc/2000-06/msg00245.html), with regard to the
behaviour of the -finstrument-functions option in connection with
functions that are inlined. A few days ago I downloaded gcc 3.2.1 and
built it without any problems on my Linux box:

~ $ gcc -v
Reading specs from
/usr/local/apps/gcc-3.2.1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs
Configured with: ../gcc-3.2.1/configure --prefix=/usr/local/apps/gcc-3.2.1
--enable-threads
Thread model: posix
gcc version 3.2.1

I tried to use again this option to make some profiling I needed, but I
noticed that the behaviour has changed. The smallest program I could
create to show (what in my opinion consists) the problem is the following
one, which is almost indentical to the one contained in the above message:

prof.c:

#include <stdio.h>

void test1(void);
void test2(void);

void __attribute__((__no_instrument_function__))
        __cyg_profile_func_enter(void *this_fn, void *call_site)
{
        printf("func_enter() : this_fn = %p, call_site = %p\n", this_fn,
call_site);
}

void __attribute__((__no_instrument_function__))
        __cyg_profile_func_exit(void *this_fn, void *call_site)
{
        printf("func_exit()  : this_fn = %p, call_site = %p\n", this_fn,
call_site);
}

void test2()
{
        printf("test2.\n");
}

void test1()
{
        printf("test1.\n");
        test2();
}

int main()
{
        printf("Hello world!!!\n");
        test1();
        return(0);
}


If I compile the program with "gcc -Wall -O4 -finstrument-functions -o
prof prof.c", the results I get are the expected ones:

func_enter() : this_fn = 0x80484c0, call_site = 0x4002f56d
Hello world!!!
func_enter() : this_fn = 0x8048470, call_site = 0x80484ed
test1.
func_enter() : this_fn = 0x8048430, call_site = 0x804849a
test2.
func_exit()  : this_fn = 0x8048430, call_site = 0x804849a
func_exit()  : this_fn = 0x8048470, call_site = 0x80484ed
func_exit()  : this_fn = 0x80484c0, call_site = 0x4002f56d

If I change the prototypes of test1() and test2() into:

inline void test1(void);
inline void test2(void);

and re-compile with the same options I get:

func_enter() : this_fn = 0x8048430, call_site = 0x4002f56d
Hello world!!!
test1.
test2.
func_exit()  : this_fn = 0x8048430, call_site = 0x4002f56d

Obviously, this time only main() was profiled. I created the assembly file
(adding the -S option) and I observed that the functions test1() and
test2() had been inlined, but there were no calls to the __cyg_profile_*
functions at the beginning and end of the inlined code. I do not know
whether this is the intended behaviour currently, but it is certainly
not in accordance with the current documentation for this option and it is
also different to older versions of gcc.

I searched yesterday all mailing lists and found several posting that
referred to this option, but I could not find why the behaviour changed.
As a programmer who has used this option several times I would like to
express my opinion about how this option should behave, in order for it to
have a useful meaning to the programmer:

1) If the -finstrument-functions option is used, the compiler should
   always create assembler code for all functions. I mention this because
   if all calls to the function are integrated into the caller, gcc does
   not produce assembly code for the function. (Is this the same as
   enabling the -fkeep-inline-functions?)

2) If a function is inlined, calls to the __cyg_profile_* functions
   should be inserted at the beginning and the end of the inlined code.
   This was the case at least up to gcc 2.95.2 (see my old message).

3) If a function is inlined, the first argument to its __cyg_profile_*
   functions should be the address of that function. As address of the
   function I mean the address that the compiler gives to the function in
   step 1. This makes it possible in every case to look up the name of the
   called function in the symbol table. This is what most of us like to
   see when we profile a program. An address that cannot be associated
   with a name does not give useful information when we are profiling. We
   need to be able to get the name. Moreover, the second argument tells us
   the function from where we were called. This is enough to create a
   correct call tree for the program and include all the information we
   wish.

   I also mention that in gcc 2.95.2 the first argument was not the
   address I propose here (again, see my old message).

4) I saw some postings about what the addresses should be when a signal or
   an exception handler is called. I really do not know what should be
   done in this case, but if we start a discussion about this we should
   include everything.


As I mentioned before, these are only my opinions and are, more or less, a
feature request. I have used the option several times and having this
experience I thought that it would be useful for you to know what I
believe is a useful behaviour for this option. At least to me, the current
behaviour is useless without the -fno-inline option at compile time, but
this option may change significantly the behaviour of the program.


Any comments on this are welcome.
Please CC to me, as I am not on the list.

Ioannis E. Venetis