[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More C++ Exceptions Issues
- Date: Mon, 3 May 1999 12:58:03 -0500 (CDT)
- From: joel at OARcorp.com (joel at OARcorp.com)
- Subject: More C++ Exceptions Issues
Sorry to be out of the loop so long on this one.
If you have the POSIX API enabled, then RTEMS supports real POSIX signals.
I believe that RTEMS does not use the newlib signal functions based on
this from the newlib configure file:
-DMALLOC_PROVIDED -DEXIT_PROVIDED -DMISSING_SYSCALL_NAMES
-DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_OPENDIR"
So you should be calling the abort in newlib which is calling
raise(). As best I can tell, RTEMS should not be using the one in
newlib but I can't find right now for some reason. :( Anyway that should
eventually call kill() (or _kill_r()) which are in c/src/exec/posix/src.
Jiri Gaisler noticed that some of the signal's default handling was
incorrect (notably the real-time signals), so it is possible that another
signal's default behavior is misconfigured. The default behavior is
defined in the array _POSIX_signals_Default_vectors in the file
It looks to me that signal 6 (SIGABRT) is configured to default to
SIGACTION_TERMINATE which installs
_POSIX_signals_Abnormal_termination_handler() to catch the signal.
This routine is implemented as follows in psignal.c:
void _POSIX_signals_Abnormal_termination_handler( int signo )
exit( 1 );
I would think that you would quietly shutdown the applicatin if all was
going well. What is happening in kill?
Also is the POSIX API enabled? The above description is wrong if
--disable-posix and ll bets are off. :)
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
On 30 Apr 1999, Ian Lance Taylor wrote:
> From: "Rosimildo DaSilva" <rdasilva at connecttel.com>
> Date: Fri, 30 Apr 1999 08:38:09 -0500
> Anyhow, RTEMS should not trap if one exception is thrown and there is
> no try block around it. Abort should be called and the application
> gracefully, as does linux. Do you suggest any place where should I be
> looking to get this fixed in RTEMS ?
> If there is no relevant try block for an exception, gcc will call
> __terminate, which will by default call the function pointed at by the
> global variable __terminate_func, which will by default point to
> __default_terminate, which will by default call abort.
> This is probably what is happening in your case.
> The RTEMS abort function is provided by newlib. It calls raise
> (SIGABRT). The raise function is also provided by newlib. It calls
> _kill_r, in newlibifr.c, which calls __kill in newlibc.c, which does
> nothing. After raise returns, abort calls _exit, which calls
> So in principle the RTEMS program should be shut down with a
> reasonable amount of grace.
> You'd better check just how abort works for your executable--it may be
> slightly different in your sources.