This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: MIPS _mcount-based profiling doesn't work with -abicalls (2.95.3)
- From: Rafal Boni <rafal at mediaone dot net>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gcc at gcc dot gnu dot org, binutils at sources dot redhat dot com
- Date: Wed, 14 Nov 2001 20:34:00 -0500
- Subject: Re: MIPS _mcount-based profiling doesn't work with -abicalls (2.95.3)
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