This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SH profiling redux
----- Original Message -----
From: "Stephen Clarke" <Stephen.Clarke@st.com>
To: <kewarken@qnx.com>
Cc: <gcc@gcc.gnu.org>
Sent: Monday, March 25, 2002 9:42 PM
Subject: Re: SH profiling redux
> kewarken@qnx.com wrote:
>
> > #define MCOUNT \
> > __asm__(".globl _mcount\n" \
> > "_mcount:\n" \
> > "mov.l __mcount_addr,r1\n" \
> > "mov.l @(4,r15),r3\n" \
> > "mov.l r4,@-r15\n" \
> > "mov.l r5,@-r15\n" \
> > "mov.l r6,@-r15\n" \
> > "mov.l r7,@-r15\n" \
> > "sts pr,r5 \n" \
> > "mov r3,r4 \n" \
> > "add #4,r5 \n" \
> ^^^
> Are you sure this inst is correct - I can't stop myself from thinking
> it ought to be "add #6,r5" ...
I'll look into this again in the morning just to be sure - I was stepping
through the generated code in the debugger and it had the right return
address - the profiling code has a .align 2 so we get a:
jsr @r0
nop
pr -> .long _mcount
pr+4 -> [rest of function]
The 'and 0xfc' is to make sure that we're on a 4 byte boundary (although it
seems that I always get the above code...) The thing is, this always works
as far as running it goes. The two problems are that I don't get call graph
data all the time and that the c++ compiler crashes on the generated
assembly. The call graph issue probably has something to do with our
generic mcount but I'm worried about the c++ thing. I'm wondering what it
is about the profiled code emission that is so invalid.
cheers,
Kris
>
> > [...]
>
> Steve.
> --
> Stephen Clarke, Principal Engineer, SuperH Inc.
> Phone:1-408-922-4062, Fax:1-408-954-8507, mailto:Stephen.Clarke@st.com
> Mail: SuperH Inc., 3801 Zanker Rd., San Jose, CA 95134, USA.
>