This is the mail archive of the gcc@gcc.gnu.org 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


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.

Cheers,

Kris

----- Original Message -----
From: "Daniel Jacobowitz" <drow@mvista.com>
To: "Kris Warkentin" <kewarken@qnx.com>
Cc: <gcc@gcc.gnu.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
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
>


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