Signal handler in RTEMS

[Joel Sherrill]

On January 2, 2015 7:53:42 PM CST, Nick Withers <nick.withers at anu.edu.au> wrote:
>Hello Ben,
>
>I'm not an RTEMS internals expert, but thought I'd try to answer this
>anyway - hopefully an expert will chime in to confirm / correct me :-)
>
>On Wed, 2014-12-31 at 13:32 -0800, Ben Dart wrote:
>> void HandleAndPrintSignal()
>> {
>>       printf("I am in the segfault signal handler AND I WILL HANDLE
>YOUR SIG!!!!\n");
>>       while(1){ printf("LALALA\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;
>>       while(1)
>>       {
>>             printf("Doing some looping\n");
>>             *(p--) = 5;
>>             printf("%d", *p);
>>       }
>> }
>> 
>> This will cause a seg fault as expected.
>
>No it won't.
>
>It'll cause a CPU exception, which is what you're seeing.
>
>RTEMS uses a single-process model; there's no "segmentation" / memory
>protection between processes (since, again, there's no such thing as
>multiple processes).
>
>> However instead of being caught by the signal handler a kernel
>routine under vectors_init.c will print the following stack trace:
>> 
>> Exception handler called for exception 12 (0xC)
>>          Next PC or Address of fault = 003506BC
>>          Saved MSR = 00003012
>>          Context: Task ID 0x0B010001
>>          R0  = 003506B8 R1  = 06827C58 R2  = 004A54F8 R3  = 00000000
>>          R4  = 06827BE8 R5  = 00000013 R6  = 06827C84 R7  = 00000001
>>          R8  = 00000000 R9  = 00000800 R10 = F0002000 R11 = F0002000
>>          R12 = 25555582 R13 = 0051A7C0 R14 = 55555555 R15 = 55555555
>>          R16 = 55555555 R17 = 55555555 R18 = 55555555 R19 = 55555555
>>          R20 = 55555555 R21 = 55555555 R22 = 06827F10 R23 = 00000001
>>          R24 = 06827D78 R25 = 003CD20C R26 = 06827D94 R27 = 00000000
>>          R28 = 006FF698 R29 = 00000013 R30 = 00000000 R31 = 1A01000E
>>          CR  = 45555582
>>          CTR = 00350EB0
>>          XER = 00000000
>>          LR  = 003506B8
>>          DAR = 00000000
>> Stack Trace:
>>   IP: 0x003506BC, LR: 0x003506B8
>> --^ 0x0038C364--^ 0x00389AF0--^ 0x0036BC5C--^ 0x00350F70--^
>0x0038AD78
>> --^ 0x0036071C--^ 0x0036D330--^ 0x0036D3B0--^ 0x0033E514--^
>0x003399D0
>> --^ 0x0033B4F0--^ 0x0033D80C--^ 0x0019B68C--^ 0x003C6934--^
>0x003C6850
>> Suspending faulting task (0x0B010001)
>> 
>> 
>> Is there something special that needs to be done to set up signal
>handlers for RTEMS? It seems like from this manual:
>> http://docs.rtems.org/doc-current/share/rtems/pdf/posix1003_1.pdf
><http://docs.rtems.org/doc-current/share/rtems/pdf/posix1003_1.pdf%20under%20section%203.3.1.1>
>> 
>> under section 3.3.1.1 indicates that signals have been implemented.
>> 
>> Is there something that I am doing wrong?
>
>You'll never get a segfault under RTEMS. That doesn't mean that invalid
>accesses to memory are "OK" though.
>
>Does that make sense?

It was hard to wait for someone else to take a shot at this. :)

Nick is right. There are some POSIX signals which are really exceptions at the hardware level. SIGSEGV, SIGBUS, and SIGFPE come to mind. The exact semantics of what is possible when when 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 something like you saw but bsp specific. 

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

Since this historically was done for Ada conformance, the common magic is in a BSP file with gnat in the name.

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. 

This looks like it came from an ARM BSP. I recall the SPARC BSPs having proper support for this. Not sure if anyone ever wrote the code to map hardware exceptions to POSIX signals for ARM.

At this point, the question is whether this was just an experiment or a needed capability with SIGSEGV.
--joel