This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: MIPS _mcount-based profiling doesn't work with -abicalls (2.95.3)
On Wed, Nov 14, 2001 at 08:34:00PM -0500, Rafal Boni wrote:
> 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..
Because the assembler knows when it's safe to use the delay slot and
when it isn't. GCC doesn't know how the branch will expand.
> [...]
> -> 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-)
Yep. It won't bite you as often.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer