Signal handler in RTEMS

The concept of this code was to test the signal handler. The end game was to catch a segmentation fault and write a log to a file, detailing the segfault and providing a primitive stack trace. Is there a better way of doing this that is not writing to file from the kernel?
I know that segfaults are bad, but in order to remove having a log of their existence would be very helpful.
Ben
From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
Sent: Monday, January 05, 2015 5:31 AM
To: Nick Withers
Cc: Ben Dart; users at rtems.org
Subject: Re: Signal handler in RTEMS
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><mailto: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><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<mailto: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/5f89aa23/attachment-0002.html>