Re: MIPS, profiling, and not working

[Jun Sun <jsun@mvista.com>]

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