MIPS, profiling, and not working

MIPS, profiling, and not working

[Daniel Jacobowitz]

I'm having some interesting problems with getting _mcount() to work on
mips*-*-linux.  Most of them are easily correctable within _mcount itself,
but one deals with how it's called.  The sequence looks like this:

        .set    noreorder
        .set    noat
        move    $1,$31          # save current return address
        jal     _mcount
        subu    $sp,$sp,8               # _mcount pops 2 words from  stack
        .set    reorder
        .set    at

Suppose we have a function with no frame pointer, though - one which would
otherwise be a leaf.  We have a small problem based on the fact that
GCC considers it to be a leaf despite calling _mcount.  If it uses $sp for
its frame register, then when the jal expands:

0x404550 <__libc_start_main+16>:        sw      $gp,16($sp)

...

0x404574 <__libc_start_main+52>:        move    $at,$ra
0x404578 <__libc_start_main+56>:        lw      $t9,-32584($gp)
0x40457c <__libc_start_main+60>:        nop
0x404580 <__libc_start_main+64>:        jalr    $t9
0x404584 <__libc_start_main+68>:        nop
0x404588 <__libc_start_main+72>:        lw      $gp,16($sp)
0x40458c <__libc_start_main+76>:        addiu   $sp,$sp,-8


Note that we saved $gp at 16($sp), then tried to restore it before we fixed
$sp up again.

Does anyone have a good idea?  The best I can think of is to emit the jalr
from GCC directly, so that we can restore the GP after restoring the stack
pointer properly.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: MIPS, profiling, and not working

[Daniel Jacobowitz]

On Wed, Aug 15, 2001 at 09:53:20AM +1000, Simon Gee wrote:
> >
> >         .set    noreorder
> >         .set    noat
> >         move    $1,$31          # save current return address
> >         jal     _mcount
> >         subu    $sp,$sp,8               # _mcount pops 2 words from  stack
> >         .set    reorder
> >         .set    at
> >
> 
> Given this assembler sequence, which is produced by:
> 
> /* Output assembler code to FILE to increment profiler label # LABELNO
>    for profiling a function entry.  */
> 
> #define FUNCTION_PROFILER(FILE, LABELNO)                                \
> {                                                                       \
>   if (TARGET_MIPS16)                                                    \
>     sorry ("mips16 function profiling");                                \
>   fprintf (FILE, "\t.set\tnoreorder\n");                                \
>   fprintf (FILE, "\t.set\tnoat\n");                                     \
>   fprintf (FILE, "\tmove\t%s,%s\t\t# save current return address\n",    \
>            reg_names[GP_REG_FIRST + 1], reg_names[GP_REG_FIRST + 31]);  \
>   fprintf (FILE, "\tjal\t_mcount\n");                                   \
>   fprintf (FILE,                                                        \
>            "\t%s\t%s,%s,%d\t\t# _mcount pops 2 words from  stack\n",    \
>            TARGET_64BIT ? "dsubu" : "subu",                             \
>            reg_names[STACK_POINTER_REGNUM],                             \
>            reg_names[STACK_POINTER_REGNUM],                             \
>            Pmode == DImode ? 16 : 8);                                   \
>   fprintf (FILE, "\t.set\treorder\n");                                  \
>   fprintf (FILE, "\t.set\tat\n");                                       \
> }
> 
> in mips.h, wouldn't the positioning of "subu $sp,$sp,8" imply that it was
> intended to be within "jal"'s delay slot (the expansion of jal is really
> annoying!) ? This being the case, the stack adjustment may have had to have
> been made before the call to _mcount is made.

*sigh* Yes, I think the adjustment was meant to be made before the
call.  Perhaps binutils should warn about things in the "delay slot" of a
macro?

Doing the adjustment before the call would fix the problem that I'm
seeing.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: MIPS, profiling, and not working

[Simon Gee]

>
>         .set    noreorder
>         .set    noat
>         move    $1,$31          # save current return address
>         jal     _mcount
>         subu    $sp,$sp,8               # _mcount pops 2 words from  stack
>         .set    reorder
>         .set    at
>

Given this assembler sequence, which is produced by:

/* Output assembler code to FILE to increment profiler label # LABELNO
   for profiling a function entry.  */

#define FUNCTION_PROFILER(FILE, LABELNO)                                \
{                                                                       \
  if (TARGET_MIPS16)                                                    \
    sorry ("mips16 function profiling");                                \
  fprintf (FILE, "\t.set\tnoreorder\n");                                \
  fprintf (FILE, "\t.set\tnoat\n");                                     \
  fprintf (FILE, "\tmove\t%s,%s\t\t# save current return address\n",    \
           reg_names[GP_REG_FIRST + 1], reg_names[GP_REG_FIRST + 31]);  \
  fprintf (FILE, "\tjal\t_mcount\n");                                   \
  fprintf (FILE,                                                        \
           "\t%s\t%s,%s,%d\t\t# _mcount pops 2 words from  stack\n",    \
           TARGET_64BIT ? "dsubu" : "subu",                             \
           reg_names[STACK_POINTER_REGNUM],                             \
           reg_names[STACK_POINTER_REGNUM],                             \
           Pmode == DImode ? 16 : 8);                                   \
  fprintf (FILE, "\t.set\treorder\n");                                  \
  fprintf (FILE, "\t.set\tat\n");                                       \
}

in mips.h, wouldn't the positioning of "subu $sp,$sp,8" imply that it was
intended to be within "jal"'s delay slot (the expansion of jal is really
annoying!) ? This being the case, the stack adjustment may have had to have
been made before the call to _mcount is made.

Simon

Re: MIPS, profiling, and not working

[Jun Sun]

Daniel Jacobowitz wrote:
> 
> On Wed, Aug 15, 2001 at 09:53:20AM +1000, Simon Gee wrote:
> > >
> > >         .set    noreorder
> > >         .set    noat
> > >         move    $1,$31          # save current return address
> > >         jal     _mcount
> > >         subu    $sp,$sp,8               # _mcount pops 2 words from  stack
> > >         .set    reorder
> > >         .set    at
> > >
> >
> > Given this assembler sequence, which is produced by:
> >
> > /* Output assembler code to FILE to increment profiler label # LABELNO
> >    for profiling a function entry.  */
> >
> > #define FUNCTION_PROFILER(FILE, LABELNO)                                \
> > {                                                                       \
> >   if (TARGET_MIPS16)                                                    \
> >     sorry ("mips16 function profiling");                                \
> >   fprintf (FILE, "\t.set\tnoreorder\n");                                \
> >   fprintf (FILE, "\t.set\tnoat\n");                                     \
> >   fprintf (FILE, "\tmove\t%s,%s\t\t# save current return address\n",    \
> >            reg_names[GP_REG_FIRST + 1], reg_names[GP_REG_FIRST + 31]);  \
> >   fprintf (FILE, "\tjal\t_mcount\n");                                   \
> >   fprintf (FILE,                                                        \
> >            "\t%s\t%s,%s,%d\t\t# _mcount pops 2 words from  stack\n",    \
> >            TARGET_64BIT ? "dsubu" : "subu",                             \
> >            reg_names[STACK_POINTER_REGNUM],                             \
> >            reg_names[STACK_POINTER_REGNUM],                             \
> >            Pmode == DImode ? 16 : 8);                                   \
> >   fprintf (FILE, "\t.set\treorder\n");                                  \
> >   fprintf (FILE, "\t.set\tat\n");                                       \
> > }
> >
> > in mips.h, wouldn't the positioning of "subu $sp,$sp,8" imply that it was
> > intended to be within "jal"'s delay slot (the expansion of jal is really
> > annoying!) ? This being the case, the stack adjustment may have had to have
> > been made before the call to _mcount is made.
> 
> *sigh* Yes, I think the adjustment was meant to be made before the
> call.  Perhaps binutils should warn about things in the "delay slot" of a
> macro?
> 

It is a reasonable warning if we are in "noreorder" state.  Programmers tend
to make assumptions about the delay slot after they do "set .noreorder".

Jun

Re: MIPS, profiling, and not working

[Maciej W. Rozycki]

On Tue, 14 Aug 2001, Daniel Jacobowitz wrote:

> *sigh* Yes, I think the adjustment was meant to be made before the
> call.  Perhaps binutils should warn about things in the "delay slot" of a
> macro?

 .set nomacro?

 There is usually no need to force an instruction into a delay slot
(unless there are nonobvious dependencies, but then you probably want to
avoid macro expansions anyway).  You may just place it before a
branch/jump and gas will move it into the slot itself if it finds it can.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +