This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Stack Checking implementation problems
- From: "Will Reece" <wreece at altera dot com>
- To: <gcc at gcc dot gnu dot org>
- Cc: "Jonah Graham" <JGRAHAM at altera dot com>,"Will Reece" <wreece at altera dot com>
- Date: Fri, 4 Feb 2005 11:39:24 -0000
- Subject: Stack Checking implementation problems
Hi all,
I am working on stack limit checking support for our gcc port, nios2.
I've adapted the approach used in allocate_dynamic_stack_space (in
explow.c), where checking is already implemented. In my
expand_prologue(), I decrement the stack and then check whether sp is
below the stack limit. This is done with an emit_cmp_and_jump_insns()
call. I then emit a trap instruction, which is jumped over if the stack
has not overflowed. This all works as expected, but breaks automatic
break points in GDB.
main:
.LFB2:
.LM1:
addi sp, sp, -4
.LCFI0:
//if checking
bgeu sp, et, .L2
.LM2:
break 3 //trap
.L2:
//end
stw fp, 0(sp)
.LCFI1:
mov fp, sp
.LCFI2:
.LM3:
mov r2, zero //checking off - stops here
.LM4:
ldw fp, 0(sp)
addi sp, sp, 4
ret
.LFE2:
Above is the asm for an empty main with checking on. If checking is off
the branch and break instructions are removed. With checking off GDB
will stop at the marked mov insn, but with checking on it does not stop
at all.
The problem seems to be that, with checking on, the break becomes the
first non-prologue insn in the function and so it is hit, after which
GDB just continues.
I can edit the debug info to correct this in two ways:
I can remove the .LM2 label (and corresponding debug info) so the break
is skipped over and the debugger correctly stops at the mov.
I can also insert another .LM label above the branch and so the debugger
stops on bgeu.
Both these are ok, but obviously the first is better.
Does anyone have any ideas for possible fixes to this problem? I have
tried marking the branch and trap insns as RTX_FRAME_RELATED_P, which
does not help. Is there a way of marking a non-frame related insn as
prologue, or of emitting dwarf2 line markers on request?
Any suggestions would be much appreciated,
Cheers!
Will Reece