-finstrument-functions and inlining problem?

Venetis Ioannis venetis@ceid.upatras.gr
Fri Jun 9 03:04:00 GMT 2000


Hi,

I have sent this also to the gcc mailing list but I haven't got any
answer. Perhaps this is the right list to ask?

I have written a little program to test the function instrumentation
capability of the gcc compiler.

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 test1()
{
 printf("test1.\n");
 test2();
}

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

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


I have compiled it with the following command :
~ # gcc -Wall -O4 -finstrument-functions prof.c -o prof

and run it :
~ # ./prof
func_enter() : this_fn = 0x80484a8, call_site = 0x4002f1eb
Hello world!!!
func_enter() : this_fn = 0x80483e4, call_site = 0x4002f1eb
test1.
func_enter() : this_fn = 0x8048428, call_site = 0x80484f8
test2.
func_exit()  : this_fn = 0x8048428, call_site = 0x80484f8
func_exit()  : this_fn = 0x80483e4, call_site = 0x4002f1eb
func_exit()  : this_fn = 0x80484a8, call_site = 0x4002f1eb

What seems odd to me is that the call_site is the same for the main() AND
the test1() functions. I expected to see a return address (I think
that is the call_site argument, right?) inside main() for the
test1() function. I have produced the assembly output (by
adding the -S switch to the above command). The problem occurs because
test1() has been inlined (I give you only the main function here) :

        .align 4 
.globl main
        .type main,@function 
main:
        pushl %ebp
        movl %esp,%ebp
        subl $8,%esp
        movl 4(%ebp),%eax
        addl $-8,%esp
        pushl %eax
        pushl $main
        call __cyg_profile_func_enter
        addl $16,%esp
        addl $-12,%esp
        pushl $.LC4
        call printf
        movl 4(%ebp),%eax
        addl $16,%esp
        addl $-8,%esp
        pushl %eax                <-- Pushing return address of main but
        pushl $test1              <-- for the test1 function
        call __cyg_profile_func_enter
        addl $16,%esp
        addl $-12,%esp
        pushl $.LC2
        call printf
        call test2
        movl 4(%ebp),%eax
        addl $16,%esp
        addl $-8,%esp
        pushl %eax
        pushl $test1
        call __cyg_profile_func_exit
        movl 4(%ebp),%eax
        addl $16,%esp
        addl $-8,%esp
        pushl %eax
        pushl $main
        call __cyg_profile_func_exit
        xorl %eax,%eax
        movl %ebp,%esp
        popl %ebp
        ret
.Lfe5:
        .size main,.Lfe5-main
        .ident  "GCC: (GNU) 2.95.2 19991024 (release)"


After compiling with this command :
~ # gcc -Wall -O4 -fno-inline -finstrument-functions prof.c -o prof
                  ^^^^^^^^^^^

I get the following output :
~ # ./prof
func_enter() : this_fn = 0x80484a8, call_site = 0x4002f1eb
Hello world!!!
func_enter() : this_fn = 0x80483e4, call_site = 0x80484d4
test1.
func_enter() : this_fn = 0x8048428, call_site = 0x8048410
test2.
func_exit()  : this_fn = 0x8048428, call_site = 0x8048410
func_exit()  : this_fn = 0x80483e4, call_site = 0x80484d4
func_exit()  : this_fn = 0x80484a8, call_site = 0x4002f1eb

which I believe is the correct one. I have also checked the assembler
output and (of course) there is no inlining for test1() in this case.

The documentation says :
     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.

I have checked the produced executable and there exists an addressable
version of the test1() function. I really don't understand what you mean
with "conceptually" in the documentation and my question is if this
behavior is expected or if this is a bug.

My gcc version :
~ #  gcc -v 
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs 
gcc version 2.95.2 19991024 (release)

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

Ioannis E. Venetis




More information about the Gcc-bugs mailing list