This is the mail archive of the
mailing list for the GCC project.
- From: "Joel Sherrill <joel at OARcorp dot com>" <joel dot sherrill at OARcorp dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: kavii ita <systemonchip2000 at yahoo dot co dot in>, gcc at gcc dot gnu dot org
- Date: Mon, 26 Jul 2004 11:09:10 -0500
- Subject: Re: stack-checking
- Organization: OAR Corporation
- References: <email@example.com> <firstname.lastname@example.org>
- Reply-to: joel dot sherrill at OARcorp dot com
Zack Weinberg wrote:
kavii ita <email@example.com> writes:
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
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. :)