Jonathan Stone wrote:
> 
> That assembly code gets used for both kernel and userlevel
> profiling. (I think userland profiling is still busted, but thats a
> story for another day).

	Its day has come! 8-) Unfortunately, it seems like gcc is emitting
garbage, so either I'm seeing things, or there's something very ugly
happening here. Here's a partial disassembly of ls_main(), a function in
the ls command:

0x400d34 <ls_main>:     lui     $gp,0xfc1
0x400d38 <ls_main+4>:   addiu   $gp,$gp,-31860
0x400d3c <ls_main+8>:   addu    $gp,$gp,$t9
0x400d40 <ls_main+12>:  addiu   $sp,$sp,-72
0x400d44 <ls_main+16>:  sw      $gp,16($sp)
0x400d48 <ls_main+20>:  sw      $ra,64($sp)
0x400d4c <ls_main+24>:  sw      $gp,60($sp)
0x400d50 <ls_main+28>:  sw      $s4,56($sp)
0x400d54 <ls_main+32>:  sw      $s3,52($sp)
0x400d58 <ls_main+36>:  sw      $s2,48($sp)
0x400d5c <ls_main+40>:  sw      $s1,44($sp)
0x400d60 <ls_main+44>:  sw      $s0,40($sp)
0x400d64 <ls_main+48>:  move    $at,$ra
0x400d68 <ls_main+52>:  lw      $t9,-32672($gp)
0x400d6c <ls_main+56>:  nop
0x400d70 <ls_main+60>:  jalr    $t9
0x400d74 <ls_main+64>:  nop
0x400d78 <ls_main+68>:  lw      $gp,16($sp)
0x400d7c <ls_main+72>:  addiu   $sp,$sp,-8
0x400d80 <ls_main+76>:  move    $s1,$a0

	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???
	-- Ethan