Re: Converting SIGSEGV etc. signals to exceptions

[Ian Lance Taylor <iant@google.com>]

sudhakar govindavajhala <sudhakarg79spam@gmail.com> writes:

> I am writing C++ code in Linux (2.6.18) using pthreads. glibc 2.5. gcc 4.1.2
>
> 1) I understand that signals SIGFPE and SIGSEGV are sent to individual
> threads while SIGINT is sent to the whole process.  How do I find out
> what signal is thread specific and what signal is process wide.  How
> does the OS/glibc determine which thread should be served the signal?
>
> 2) I would like to translate SIGSEGV or SIGFPE to an exception in the
> program so that it can be caught at higher levels. Is there a default
> option to convert a SIGSEGV to an exception?  For my tests, I provided
> a signal handler for SIGSEGV/SIGFPE that throws an int exception and
> it works. Is it legal to throw exceptions in signal handlers? Is there
> any limitation on what kind of object can be thrown as an exception?
> Could someone help me understand the rules in this space?
>
> 3) Could someone point me to  a sample to print the stack trace when
> an exception occurred?


This message is not appropriate for the mailing list gcc@gcc.gnu.org,
which is for gcc developers.  It would be appropriate for
gcc-help@gcc.gnu.org.  Please take any followups to gcc-help.  Thanks.

1) This is a question about the OS, not about gcc.  Any signal sent
using pthread_kill will be thread-specific.  Any signal generated by the
execution of an instruction will be thread-specific.  I don't know which
signals those are on GNU/Linux, but I suspect they are SIGSEGV, SIGFPE,
SIGILL, SIGBUS, and SIGTRAP.  There may be others.  A signal not
generated by the execution of an instruction would be one generated by a
call to raise or kill, or one trigged from the terminal such as SIGINT,
or one generated by the kernel on behalf of the program such as SIGIO or
SIGPIPE.

2) On GNU/Linux gcc supports using throw in a signal handler.  There are
no restrictions on what object you may throw.  Note that the operating
system imposes restrictions on what code you may run in a signal
handler.  E.g., it would be unwise to throw an object which use a
constructor which allocates memory.

3) man backtrace.

Ian