Profiling Implementation Issue with GCC C/C++ cross for PowerPC

Question

I'm trying to get the gcc profiling implemented.

I am using the embedded environment eCos with a PowerPC. I programming in C.

When I compile and link using the -pg switch, I find that the symbol _mcount is undefined.

I realize I need to implement this function as it is target specific.

What are the requirements for the _mcount function?

Am I correct that it must save and restore all registers? Are there any special registers that have to be saved and restored along with the standard 32?

I have seen commments stating that _mcount must be called with interrupts disabled, or does _mcount disable interrupts before recorded the call tree data?

My PowerPC is an 8245. This is a 603e family processor.

I am using GCC 4.6.1 built as a cross-compiler as powerpc-eabi.

Here's an example of the _mcount call generate by gcc. The first instruction of the function being profiled is the first line shown:

100b40:       7c 08 02 a6     mflr    r0
100b44:       3d 80 00 23     lis     r12,35
100b48:       90 01 00 04     stw     r0,4(r1)
100b4c:       38 0c 82 a8     addi    r0,r12,-32088
100b50:       48 05 19 25     bl      152474 <_mcount>
100b54:       94 21 ff 88     stwu    r1,-120(r1)
100b58:       7c 08 02 a6     mflr    r0
100b5c:       90 01 00 7c     stw     r0,124(r1)
100b60:       93 e1 00 74     stw     r31,116(r1)
100b64:       7c 3f 0b 78     mr      r31,r1

The code created by the compiler switch -pg performs the following.

• 1) The address of the caller is stored on the stack with two instruction mflr r0 and stw r0,4(r1).
• 2) The address of the function just entered is stored in r0 with the two instructions lis r12,35 and addi r0,r12,-32088.

Thus when _mcount is called r0 contains the entered function address, 4(r1) contains the program counter of the caller. This pair of information is stored and used to create the call graph.

This information I found by reading the gcc source, gcc/libffi/src/powerpc/asm.h.

I'm still unsure what _mcount is expected to return. It appears it has to restore LR, so that _mcount can't use blr, it has to restore LR from (4)r1 and use a jump instruction instead of blr to return to the instruction after bl _mcount. Does this make sense?

Answer 1

This is not a complete solution, but the assembly code below will create a dummy _mcount for PowerPC.

The code can be used to resolve the _mcount external, but no call graph data is recorded. This code was suggested by the gcc file \gcc\testsuite\gcc.target\powerpc\ppc-abi-2.c, function my_mcount()

    .text                
    .globl  _mcount
_mcount:
    # Move LR to CTR and return via CTR
    mflr r0
    mtctr r0
    lwz r0,4(r1)
    mtlr r0
    bctr

Answer 2

There's an implementation of _mcount for PowerPC now checked-in to the eCos RTOS repository:

http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/packages/hal/powerpc/arch/current/src/mcount.S?cvsroot=ecos