* MIPS, profiling, and not working
@ 2001-08-14 22:09 Daniel Jacobowitz
2001-08-14 23:53 ` Simon Gee
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2001-08-14 22:09 UTC (permalink / raw)
To: linux-mips, gcc-bugs; +Cc: Simon Gee
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: MIPS, profiling, and not working 2001-08-14 22:09 MIPS, profiling, and not working Daniel Jacobowitz @ 2001-08-14 23:53 ` Simon Gee 2001-08-14 23:44 ` Daniel Jacobowitz 0 siblings, 1 reply; 5+ messages in thread From: Simon Gee @ 2001-08-14 23:53 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: linux-mips, gcc-bugs > > .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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MIPS, profiling, and not working 2001-08-14 23:53 ` Simon Gee @ 2001-08-14 23:44 ` Daniel Jacobowitz 2001-08-15 0:11 ` Jun Sun 2001-08-16 10:12 ` Maciej W. Rozycki 0 siblings, 2 replies; 5+ messages in thread From: Daniel Jacobowitz @ 2001-08-14 23:44 UTC (permalink / raw) To: Simon Gee; +Cc: linux-mips, gcc-bugs 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MIPS, profiling, and not working 2001-08-14 23:44 ` Daniel Jacobowitz @ 2001-08-15 0:11 ` Jun Sun 2001-08-16 10:12 ` Maciej W. Rozycki 1 sibling, 0 replies; 5+ messages in thread From: Jun Sun @ 2001-08-15 0:11 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Simon Gee, linux-mips, gcc-bugs 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: MIPS, profiling, and not working 2001-08-14 23:44 ` Daniel Jacobowitz 2001-08-15 0:11 ` Jun Sun @ 2001-08-16 10:12 ` Maciej W. Rozycki 1 sibling, 0 replies; 5+ messages in thread From: Maciej W. Rozycki @ 2001-08-16 10:12 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Simon Gee, linux-mips, gcc-bugs 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 + ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-08-16 10:11 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2001-08-14 22:09 MIPS, profiling, and not working Daniel Jacobowitz 2001-08-14 23:53 ` Simon Gee 2001-08-14 23:44 ` Daniel Jacobowitz 2001-08-15 0:11 ` Jun Sun 2001-08-16 10:12 ` Maciej W. Rozycki
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.