<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas","serif";
color:black;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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? <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I know that segfaults are bad, but in order to remove having a log of their existence would be very helpful. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Ben <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> Joel Sherrill [mailto:joel.sherrill@oarcorp.com] <br><b>Sent:</b> Monday, January 05, 2015 5:31 AM<br><b>To:</b> Nick Withers<br><b>Cc:</b> Ben Dart; users@rtems.org<br><b>Subject:</b> Re: Signal handler in RTEMS<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>FWIW I wanted to double check that what I said matched the executable<br>behavior. I ran on sparc/sis and got this back trace in gdb<span style='font-size:10.0pt'>:<br><br>BENS BIG NOTE: Initializing Signal Handler<br>Doing some looping<br><br>Breakpoint 1, _Terminate (<br> the_source=the_source@entry=RTEMS_FATAL_SOURCE_EXCEPTION, <br> is_internal=is_internal@entry=false, the_error=the_error@entry=33693512)<br> at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36<br>36 {<br>(gdb) bt<br>#0 _Terminate (the_source=the_source@entry=RTEMS_FATAL_SOURCE_EXCEPTION, <br> is_internal=is_internal@entry=false, the_error=the_error@entry=33693512)<br> at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36<br>#1 0x02007e80 in rtems_fatal (<br> source=source@entry=RTEMS_FATAL_SOURCE_EXCEPTION, <br> error=error@entry=33693512)<br> at ../../../../../../rtems/c/src/../../cpukit/sapi/src/fatal2.c:34<br>#2 0x02001b6c in bsp_spurious_handler (trap=265, isf=0x2025db0)<br> at ../../../../../../../../rtems/c/src/lib/libbsp/sparc/erc32/startup/spurious.c:131<br><br><br>Just as Nick and I thought, you dereferenced a NULL pointer and caused an access violation. <br>The processor gave a hardware exception and the BSP caught it. If code is installed which<br>maps hardware exceptions -> POSIX signals, then you would have gotten the behavior you<br>expected.<br><br>--joel</span><o:p></o:p></p><div><p class=MsoNormal>On 1/2/2015 8:13 PM, Nick Withers wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>On Fri, 2015-01-02 at 20:06 -0600, Joel Sherrill wrote:<o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre><o:p> </o:p></pre><pre>On January 2, 2015 7:53:42 PM CST, Nick Withers <a href="mailto:nick.withers@anu.edu.au"><nick.withers@anu.edu.au></a> wrote:<o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Hello Ben,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>I'm not an RTEMS internals expert, but thought I'd try to answer this<o:p></o:p></pre><pre>anyway - hopefully an expert will chime in to confirm / correct me :-)<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>On Wed, 2014-12-31 at 13:32 -0800, Ben Dart wrote:<o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>void HandleAndPrintSignal()<o:p></o:p></pre><pre>{<o:p></o:p></pre><pre> printf("I am in the segfault signal handler AND I WILL HANDLE<o:p></o:p></pre></blockquote><pre>YOUR SIG!!!!\n");<o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre> while(1){ printf("LALALA\n"); }<o:p></o:p></pre><pre> exit(1);<o:p></o:p></pre><pre>}<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>void *POSIX_Init(void *args)<o:p></o:p></pre><pre>{<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> printf("BENS BIG NOTE: Initializing Signal Handler\n");<o:p></o:p></pre><pre> struct sigaction sa;<o:p></o:p></pre><pre> sa.sa_handler = HandleAndPrintSignal;<o:p></o:p></pre><pre> sigemptyset(&sa.sa_mask);<o:p></o:p></pre><pre> sa.sa_flags = SA_SIGINFO;<o:p></o:p></pre><pre> if (sigaction (SIGSEGV, &sa, 0)) {<o:p></o:p></pre><pre> printf("A ERROR OCCURED WITH THIS!");<o:p></o:p></pre><pre> exit(1);<o:p></o:p></pre><pre> }<o:p></o:p></pre><pre> int *p = NULL;<o:p></o:p></pre><pre> while(1)<o:p></o:p></pre><pre> {<o:p></o:p></pre><pre> printf("Doing some looping\n");<o:p></o:p></pre><pre> *(p--) = 5;<o:p></o:p></pre><pre> printf("%d", *p);<o:p></o:p></pre><pre> }<o:p></o:p></pre><pre>}<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>This will cause a seg fault as expected.<o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><pre>No it won't.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>It'll cause a CPU exception, which is what you're seeing.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>RTEMS uses a single-process model; there's no "segmentation" / memory<o:p></o:p></pre><pre>protection between processes (since, again, there's no such thing as<o:p></o:p></pre><pre>multiple processes).<o:p></o:p></pre><pre><o:p> </o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>However instead of being caught by the signal handler a kernel<o:p></o:p></pre></blockquote><pre>routine under vectors_init.c will print the following stack trace:<o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre><o:p> </o:p></pre><pre>Exception handler called for exception 12 (0xC)<o:p></o:p></pre><pre> Next PC or Address of fault = 003506BC<o:p></o:p></pre><pre> Saved MSR = 00003012<o:p></o:p></pre><pre> Context: Task ID 0x0B010001<o:p></o:p></pre><pre> R0 = 003506B8 R1 = 06827C58 R2 = 004A54F8 R3 = 00000000<o:p></o:p></pre><pre> R4 = 06827BE8 R5 = 00000013 R6 = 06827C84 R7 = 00000001<o:p></o:p></pre><pre> R8 = 00000000 R9 = 00000800 R10 = F0002000 R11 = F0002000<o:p></o:p></pre><pre> R12 = 25555582 R13 = 0051A7C0 R14 = 55555555 R15 = 55555555<o:p></o:p></pre><pre> R16 = 55555555 R17 = 55555555 R18 = 55555555 R19 = 55555555<o:p></o:p></pre><pre> R20 = 55555555 R21 = 55555555 R22 = 06827F10 R23 = 00000001<o:p></o:p></pre><pre> R24 = 06827D78 R25 = 003CD20C R26 = 06827D94 R27 = 00000000<o:p></o:p></pre><pre> R28 = 006FF698 R29 = 00000013 R30 = 00000000 R31 = 1A01000E<o:p></o:p></pre><pre> CR = 45555582<o:p></o:p></pre><pre> CTR = 00350EB0<o:p></o:p></pre><pre> XER = 00000000<o:p></o:p></pre><pre> LR = 003506B8<o:p></o:p></pre><pre> DAR = 00000000<o:p></o:p></pre><pre>Stack Trace:<o:p></o:p></pre><pre> IP: 0x003506BC, LR: 0x003506B8<o:p></o:p></pre><pre>--^ 0x0038C364--^ 0x00389AF0--^ 0x0036BC5C--^ 0x00350F70--^<o:p></o:p></pre></blockquote><pre>0x0038AD78<o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>--^ 0x0036071C--^ 0x0036D330--^ 0x0036D3B0--^ 0x0033E514--^<o:p></o:p></pre></blockquote><pre>0x003399D0<o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>--^ 0x0033B4F0--^ 0x0033D80C--^ 0x0019B68C--^ 0x003C6934--^<o:p></o:p></pre></blockquote><pre>0x003C6850<o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Suspending faulting task (0x0B010001)<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>Is there something special that needs to be done to set up signal<o:p></o:p></pre></blockquote><pre>handlers for RTEMS? It seems like from this manual:<o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre><a href="http://docs.rtems.org/doc-current/share/rtems/pdf/posix1003_1.pdf">http://docs.rtems.org/doc-current/share/rtems/pdf/posix1003_1.pdf</a><o:p></o:p></pre></blockquote><pre><a href="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></a><o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre><o:p> </o:p></pre><pre>under section 3.3.1.1 indicates that signals have been implemented.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Is there something that I am doing wrong?<o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><pre>You'll never get a segfault under RTEMS. That doesn't mean that invalid<o:p></o:p></pre><pre>accesses to memory are "OK" though.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Does that make sense?<o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><pre>It was hard to wait for someone else to take a shot at this. :)<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>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. <o:p></o:p></pre><pre><o:p> </o:p></pre><pre>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. <o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Since this historically was done for Ada conformance, the common magic is in a BSP file with gnat in the name.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>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. <o:p></o:p></pre><pre><o:p> </o:p></pre><pre>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.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>At this point, the question is whether this was just an experiment or a needed capability with SIGSEGV.<o:p></o:p></pre><pre>--joel<o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><pre>Thanks Joel.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Even if a signal was emitted for this case, I'd argue SIGBUS would be<o:p></o:p></pre><pre>more appropriate than SIGSEGV...?<o:p></o:p></pre></blockquote><p class=MsoNormal><br><br><o:p></o:p></p><pre>-- <o:p></o:p></pre><pre>Joel Sherrill, Ph.D. Director of Research & Development<o:p></o:p></pre><pre><a href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research<o:p></o:p></pre><pre>Ask me about RTEMS: a free RTOS Huntsville AL 35805<o:p></o:p></pre><pre>Support Available (256) 722-9985<o:p></o:p></pre></div></body></html>