Signal handler in RTEMS
Joel Sherrill
joel.sherrill at oarcorp.com
Mon Jan 5 13:30:59 UTC 2015
FWIW I wanted to double check that what I said matched the executable
behavior. I ran on sparc/sis and got this back trace in gdb:
BENS BIG NOTE: Initializing Signal Handler
Doing some looping
Breakpoint 1, _Terminate (
the_source=the_source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
is_internal=is_internal at entry=false, the_error=the_error at entry=33693512)
at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36
36 {
(gdb) bt
#0 _Terminate (the_source=the_source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
is_internal=is_internal at entry=false, the_error=the_error at entry=33693512)
at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36
#1 0x02007e80 in rtems_fatal (
source=source at entry=RTEMS_FATAL_SOURCE_EXCEPTION,
error=error at entry=33693512)
at ../../../../../../rtems/c/src/../../cpukit/sapi/src/fatal2.c:34
#2 0x02001b6c in bsp_spurious_handler (trap=265, isf=0x2025db0)
at
../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/startup/spurious.c:131
Just as Nick and I thought, you dereferenced a NULL pointer and caused
an access violation.
The processor gave a hardware exception and the BSP caught it. If code
is installed which
maps hardware exceptions -> POSIX signals, then you would have gotten
the behavior you
expected.
--joel
On 1/2/2015 8:13 PM, Nick Withers wrote:
> On Fri, 2015-01-02 at 20:06 -0600, Joel Sherrill wrote:
>> 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
> Thanks Joel.
>
> Even if a signal was emitted for this case, I'd argue SIGBUS would be
> more appropriate than SIGSEGV...?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20150105/cbc758bf/attachment-0002.html>
More information about the users
mailing list