stack-checking

stack-checking

[kavii ita]

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.

1. One solution is to reserve some stack space for
printf
etc. and signal the stack overflow
early, but that's not correct since the application
has not really exhausted the stack as of
yet.

2. another solution is to use the lower level calls
which actually prints (_write()) the string, but i
would like to format e.g.. The error messages whould
indicate the function name in which it occured etc. 

Please suggest what is the correct way to perform
stack checking in absence of OS.

Regards,
ita

________________________________________________________________________
Yahoo! India Careers: Over 65,000 jobs online
Go to: http://yahoo.naukri.com/

Re: stack-checking

[Zack Weinberg]

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.

zw

Re: stack-checking

[Joel Sherrill <joel@OARcorp.com>]

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

Global object initialisation doesn't work ??

[kavii ita]

Hello,
My g++ compiler doesn't generate the .ctor and dtor
sections. 
So the global obects in the code doesn't work. 
The following test case works.

When I see the objdump/readelf of the hello.c, it
shows the 
/ctor section coming empty.

how do put the [cd]tor section content in to the code
?
I am using 3.3. compiler.

I came to know that crtbegin, crtend ojects are needed
to be linked for c++. Is this right?
==============================================
hello.c
================================
#include <stdio.h>
int main () 
{
class A { 

public: 
A ()
{
  printf ("Public hello ! "); 
} 
};

A a;

}

================================
But this test case doesn't work.
================================

#include <stdio.h>

class A 
{ 
	public: 
	A ()
	{
	  printf ("Public hello ! "); 
	} 
};

A a;

int main () 
{ 

}
================================


-kavii


________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony

Re: Global object initialisation doesn't work ??

[James E Wilson]

kavii ita wrote:
> My g++ compiler doesn't generate the .ctor and dtor
> sections. 

There are many different ways to implement static constructors, and many 
different things that can go wrong.  Without more info, we can't do 
anything to help you.

We need to know what the target is.  We need to know how you are 
compiling it.  We need to know what if any changes you have made to gcc. 
  Etc.  We need to know everything necessary in order for one of us to 
reproduce the problem you are seeing.

Using gcc-3.3.3, the testcase works for me on an x86_64-linux system.  I 
don't see anything obviously wrong.

 >I came to know that crtbegin, crtend ojects are needed
 >to be linked for c++. Is this right?

For most ELF targets, yes.  But the compiler takes care of this for you, 
so this isn't something you should need to worry about.  Unless maybe 
you are writing your own port, but you didn't mention that.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com