>
> .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
