Subject: Re: mips kernel profiling?
To: Michael L. Hitch <mhitch@lightning.msu.montana.edu>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-mips
Date: 04/19/2000 20:50:53
In message <Pine.ULT.4.05.10004192105070.9836-100000@lightning.msu.montana.edu>
"Michael L. Hitch" writes:
>
> I would say that you have an out-of-date compiler. A little test
>program gives me:
> 24: 03e00821 move $at,$ra
> 28: 27bdfff8 addiu $sp,$sp,-8
> 2c: 8f990000 lw $t9,0($gp)
> 2c: R_MIPS_CALL16 _mcount
> 30: 00000000 nop
> 34: 0320f809 jalr $t9
> 38: 00000000 nop
>
> The source file generated by cc1 is:
> .set noreorder
> .set noat
> move $1,$31 # save current return address
> subu $sp,$sp,8 # _mcount pops 2 words from stack
> jal _mcount
> nop
> .set reorder
> .set at
Which is why we better do ".set noat" around the _mcount glue code in
profile.h. (I knew there was a good reason for it.)
Should we add a cmment to that effect?
can we change the $1 in the MCOUNT macro to $at, or do we have to pull
in the sybomlic register definitions (does that pollute the
user namespace)?
[snip]
That sounds familiar... but I have a nasty feeling that after Ethan
updates his compiler, he'll lock his machine up when it tries to
deliver a SIGPROF to the profiled process.