This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Mips profiling
Sorry I missed this the first time...
On Thu, Mar 21, 2002 at 02:26:08PM -0500, Kris Warkentin wrote:
> Replying to myself with some more observations - it seems that profiled code
> on mips when compiled with optimization level -O2 is invalid. I've verified
> it on QNX6 (2.95.3) and Irix (3.0.1). As near as I can tell from my
> preliminary analysis, somewhere along the line the ra register is getting
> clobbered and we wind up executing instructions off in the wild blue yonder.
>
> cheers,
>
> Kris
> ----- Original Message -----
> From: "Kris Warkentin" <kewarken@qnx.com>
> To: <gcc@gcc.gnu.org>
> Sent: Thursday, March 21, 2002 10:29 AM
> Subject: Mips profiling
>
>
> > I've been looking at the following chunk of code from
> gcc/config/mips/mips.h
> > and something is puzzling me. The bit about 'mcount pops 2 words from
> > stack' seems wrong. I believe the first four arguments to a function in
> > mips will be passed in registers and the stack won't be involved. If I
> read
> > this correctly, we're leaking 8 bytes of stack memory per function call.
_mcount is not a normal function. It is not called like a normal
function; it is not allowed to clobber registers in the same way that a
normal function is.
See the (current CVS head, not any release!) version of _mcount in GNU
libc: sysdeps/mips/machine-gmon.h.
Basically, the calling convention is:
no registers will be saved/restored around a call to _mcount
the original value of $ra will be passed in $at
(and of course the return address to return to in $ra)
restore $ra before you leave
pop two words off the stack before you exit
This is a somewhat unfortunate calling convention, but dates from many
years ago - I'm not sure precisely what compiler originally set it.
> > The other question would be 'why don't we have something in the branch
> delay
> > slot of jal _mcount'? Wouldn't this cause problems depending on what this
> > code was inserted before? Or did removing the '.set noreorder' which used
> > to be in front of '.set noat' take care of this?
Without .set noreorder, the assembler (not compiler) is responsible for
filling delay slots.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer