This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

profiling using _mcount in gcc


Hi

I am trying to do some profiling on a MIPS based embedded system using the
gcc's -pg option using the Tornado 2.0 devlopment environment. I compile a
file with the -pg option to profile all the functions inside that particular
file. I have implemented a _mcount() fnction which the compiler will call...
The strange thing is that the compiler generates two sets of assembly code
for two sets of functions..

COnsider a function foo() which does not have calls to any other function
except the compiler inserted _mcount() function call. 
The assembly code looks something like this..

8081c76c:  addiu        sp,sp,-8           
8081c770:  sw           s8,0(sp)           
8081c774:  move         s8,sp              
8081c778:  move         at,ra              
8081c77c:  jal          0x8080a408          # _mcount
8081c780:  addiu        sp,sp,-8           
8081c784:  sw           a0,8(s8)           
8081c788:  sw           a1,12(s8)          

Here the return address is not stored in the stack . Its only stored in the
at register. But whicl ereturning from this function the return address is
not obtained from the at register. Instaed it returns by just doing jr $ra.
This results in a loop since the return address is ra is not the correct one
when this function foo() has to return. 


Now consider another function fooEx() which makes a call to a function in
addition to the compiler called _mcount(). In this cas e the assembly code
looks something like this.

8081bcc8:  addiu        sp,sp,-32          
8081bccc:  sw           ra,28(sp)          
8081bcd0:  sw           s8,24(sp)          
8081bcd4:  move         s8,sp              
8081bcd8:  move         at,ra              
8081bcdc:  jal          0x8080a408          # _mcount
8081bce0:  addiu        sp,sp,-8           

Here the return address is stored in the stack and is popped out of the
stack at the end before returning.  This works fine.

Any clues/ideas on why this is behaving this way in the first case of
function foo(). 

Any help would be greatly appreciated...

Thanks
Venkatesh




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]