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.