Signal handler in RTEMS

[Nick Withers]

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?
-- 
Nick Withers

Embedded Systems Programmer
Department of Nuclear Physics, Research School of Physics and Engineering
The Australian National University (CRICOS: 00120C)