Re: MIPS _mcount-based profiling doesn't work with -abicalls (2.95.3)

[Rafal Boni <rafal at mediaone dot net>]

In message <20011114195005.A8142@nevyn.them.org>, you write: 

-> > 	I include here two patches for this problem.  The first is just a 
-> > 	simple re-schedule of the FUNCTION_PROFILER macro which does the
-> > 	stack adjust before the `jal' always.  This certainly works, and
-> > 	is the safer of the two solutions, but may cost some performance
-> > 	in the non-abicalls call where this is not needed.
-> 
-> This is a solution.  It's not enough of a solution, though.  I'm fairly
-> certain that GCC's MIPS _mcount ABI originally comes from RiscOS or
-> something of that time period, from the archaeology I did.  That was
-> before abicalls and PIC, and the jal had a delay slot to use :)
-> 
-> So this patch is right.  I submitted a similar one several months ago. 
-> It's wiser to remove .set noreorder and let the assembler cope.

Ah, cool.  As to eliding the .set noreorder, why would this be a win? I'd
think it'd be safer with it..

[...]
-> You'll have another problem.  If you try to compile a nested function
-> (C monstrosity that they are) you'll die in the inner one.  GCC will
-> push $v0 onto the stack, jal (which the assembler will try to expand
-> into a GP restore, from the incorrect stack pointer), and then pop $v0. 
-> This can also happen with (I think) structure returns.

If I parse you right, this is independent of the above fix, right?
I'll give this a whirl just for kicks to see how badly I lose 8-)

-> I suppressed the stack push/pop entirely and changed my C library to
-> save $v0 in _mcount.  I posted at least the GCC parts of this, too.

Thanks for the feedback!
--rafal

----
Rafal Boni                                                  rafal@mediaone.net