Subject: Re: mips kernel profiling?
To: Ethan Solomita <ethan@geocast.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-mips
Date: 04/19/2000 17:27:40
In message <38FE4C3B.CD51C8DA@geocast.com>Ethan Solomita writes
>Jonathan Stone wrote:


>	This is built with -pg, and the jalr at ls_main+0x60 is the call to
>mcount. Here's what is so confused: normally, it has to do the add -8 to
>$sp, as it does in ls_main+72, *before* the call to mcount()! But it is
>doing it not only after mcount, but also after it reloads $gp from the
>wrong address. So mcount() ends up trampling on 8 bytes of our stack,
>and we reload the wrong location for $gp.
>
>	Anyone have any clues why it's doing this???

sort of, yes, but its hairy, and the symptoms with egcs seem somewhat
different than the gcc-2.7.x derived code I examined.

One thing that may be going wrong is that GCC is completely unaware of
the call to mcount() which we're splicing in. So its adjustment of $gp
(which is correct for main()) is all whacked for mcount().

Oh yes, and that reminds me of one more reason to do the .set noat in
the code Simon asked about, since when function A calls mcount() to
instrument itself (A()) the call into mcount() keeps the return
address (within A's function prologue) in $at. Otherwise it would
clobber the address of $a's caller.


Ethan: what happens if you acutally run this?  Does your machine lock
up, or do you quickly get a coredump?

(PS: Take this with a _big_ grain of salt, I'm working on a SIGCOMM
 paper and we're out of coffee filters...)