2

To begin with I will point out the operating system here is RTEMS, it is an Open source RTOS and the source can be found here:

http://git.rtems.org/rtems/

I have a pretty simple program that sets up a signal handler for SIGSEGV (which i believe is supported) using sigaction call from the documentation here:

http://docs.rtems.org/releases/rtemsdocs-4.9.2/share/rtems/html/posix_users/posix_users00033.html

My program essentially boils down to this:

void HandleAndPrintSignal()
{
    printf("I am in the segfault signal handler AND I WILL HANDLE YOUR SIG!!!!\n");
    exit(1);
}

void *POSIX_Init(void *args)
{
    printf("BENS BIG NOTE: Initializing Signal Handler\n");
    struct sigaction sa;
    sa.sa_handler = HandleAndPrintSignal;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_SIGINFO;
    if (sigaction (SIGSEGV, &sa, 0)) {
      printf("A ERROR OCCURED WITH THIS!");
      exit(1);
    }

    int *p = NULL;
    *(p--) = 5; // Causes segfault
}

However, the problem is that when i cause a segfault in my program, the signal handler is not called but instead a kernel process is called in vectors_init.c (RTEMS source) to print a stack trace. Is there something special that I need to do to get SIGSEGV signal in my rtems program?

Fantastic Mr Fox
  • 32,495
  • 27
  • 95
  • 175
  • Do RTEMS fully support POSIX signal handling? – Some programmer dude Dec 31 '14 at 00:30
  • @JoachimPileborg As far as i can tell it does: http://docs.rtems.org/doc-current/share/rtems/pdf/posix1003_1.pdf under section 3.3.1.1, it specifies signals and SIGSEGV as implemented. – Fantastic Mr Fox Dec 31 '14 at 00:31
  • I don't think you call either `printf` or `exit` from a signal handler. – David Schwartz Dec 31 '14 at 01:16
  • @davidschwartz you can call them but they are not asynchronous so its not good practice. I will deal with that when i actually get the signal handler working. – Fantastic Mr Fox Dec 31 '14 at 01:18
  • @Ben Why do you say you can call them? See, for example, [this](https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers). – David Schwartz Dec 31 '14 at 01:20
  • @DavidSchwartz Just because it is bad practice doesn't mean it cant be done: http://ideone.com/odQMt0. The plan is to deal with this in an asynchronous way once I have figured out why signals are not working at all. – Fantastic Mr Fox Dec 31 '14 at 01:48
  • Not that it should matter, but may as well play by all the rules. Since you're using `sigemptyset` may as well also use `sigaddset`. – WhozCraig Dec 31 '14 at 03:13
  • @WhozCraig thank, i will change that in the working code. Still trying to get the thing functioning however. – Fantastic Mr Fox Dec 31 '14 at 17:57

1 Answers1

0

So the explanation of this is that RTEMS does not handle signals the way that I thought it does.

There are some POSIX signals which are really exceptions at the hardware level. for eg. SIGSEGV, SIGBUS, and SIGFPE. The exact semantics of what is possible when this occurs is defined by POSIX but the magic starts with an architecture and BSP specific handler. Since the general rule is to avoid these faults in embedded systems, the default action is often something like a kernal stack trace, or other BSP specific code.

Some BSPs have support for installing an addition to the exception handler which will propagate the hardware fault into a software signal but this is primarily used to get SIGFPE in languages like Ada mapped to language specific exception handlers.

As a general rule, POSIX signals are rarely used in embedded systems, those that originate in hardware exceptions are designed out and considered unrecoverable faults, and the software only signals may be used.

As a summary: in order to get the desired behavior i need code that is installed which maps hardware exceptions -> POSIX signals.

Fantastic Mr Fox
  • 32,495
  • 27
  • 95
  • 175