On Fri, 31 Mar 2000, Ethan Solomita wrote:

> 	I've tracked this down, since I am trying to get profiling working too.
> I've tracked it down to the _mcount function, but it has been the way it
> is for a real long time now, so I'm confused as to how it ever worked.
> 
> 	In _mcount, defined as an assembler routine in arch/mips/profile.h, it
> saves various registers to 0(sp) through 20(sp). Unfortunately, looking
> at the call into _mcount from various functions, it decrements sp by 8,
> and _mcount doesn't decrement it further. ie. _mcount appears to be
> writing all over the caller's stack!
> 
> 	But clearly this worked for someone at some point, so what am I
> missing? The failure in fork1() above happens because main() called
> siginit(), siginit() calls _mcount(), and that trashes main's proc
> pointer in the stack. So fork1 is passed a bogus proc pointer.

  I recall looking at this a while ago, and as best I can remember, I came
to the conclusion that egcs was generating code differently then the
previous version of gcc.  I think _mcount was relying upon a valid stack
frame to be set up by gcc prior to calling _mcount and before storing
anything into that stack frame (i.e. the call to _mcount expects the stack
frame to be set up with space to save a0-a3, and adjusts the stack to
include space for saving two more registers).  Egcs apparently does not
follow this convention in all cases, and _mcount has not been modified to
take this into account yet.

--
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA