This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stack-checking


Zack Weinberg wrote:
kavii ita <systemonchip2000@yahoo.co.in> writes:


hello,

I am working on an embedded system, which runs elf images and have
no underlying OS.

I have modified GCC to check at the start of each function whether
the current stack pointer is out of range..i.e. to check stack
overflow.

My problem is how can I print diagnostic messages when stack
overflow occurs?  Since once the overflow occurs , the functions
printf etc does not work as they themselves need stack space.


This question is more suited to an embedded-operating-system
development forum, but I don't know of one offhand, so I'll give you a
suggestion:  Have gcc respond to stack overflow by issuing a hardware
trap.  Give the trap handler its own stack (all modern CPUs can do
that).  Then you have space to issue an error message.

Depending upon the C library and implementation of the underlying write, you then need to be careful to ensure that the way the trap handler does output doesn't conflict with that of the application. You mention using printf() -- don't. Use a simple routine that polls characters out a debug port. printf() might have been the culprit for the stack overflow. Also, printf() might be tied to an interrupt driven device and you probably don't want to take a chance on the output actually getting out.

Detecting the overflow is another matter.  In an embedded
system you have complete control over where the stack is,
so you know the limits.  The most reliable solution if you
have the capability is to use the MMU to map your stack
such that overflow or underflow will result in accesses
of unmapped memory.  Otherwise, you probably are going to
have to depend on hand placed checks/probes and/or check
in an ISR.

RTEMS' stack checking also writes a known pattern in the
memory.  Periodically, we check to see if the portion at
the stack limits for a task have changed.  If so, you
are too close. :)


zw

--joel



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]