This is the mail archive of the 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]
Other format: [Raw text]

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" <>
> To: <>
> 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

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