This is the mail archive of the
mailing list for the GCC project.
Re: Mips profiling
Well, that possibly explains the ra issue...I'll look at our code to see
what happens to it. Seems odd to me that it fails on optimized code only.
We're also seeing some problems with bus errors when we compile C++ with
profiling but I haven't followed that up yet.
----- Original Message -----
From: "Daniel Jacobowitz" <email@example.com>
To: "Kris Warkentin" <firstname.lastname@example.org>
Sent: Thursday, March 21, 2002 3:30 PM
Subject: 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
> > on mips when compiled with optimization level -O2 is invalid. I've
> > 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
> > clobbered and we wind up executing instructions off in the wild blue
> > cheers,
> > Kris
> > ----- Original Message -----
> > From: "Kris Warkentin" <email@example.com>
> > To: <firstname.lastname@example.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
> > > mips will be passed in registers and the stack won't be involved. If
> > read
> > > this correctly, we're leaking 8 bytes of stack memory per function
> _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
> > > code was inserted before? Or did removing the '.set noreorder' which
> > > 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